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Abstract 

Lightning  has  an  impact  on  Air  Force  operations  in  the  air  and  on  the  ground.  Delays  to 
flight  or  maintenance  activities  are  some  of  the  common  consequences  that  result  from 
thunderstorms  approaching  an  active  airfield.  These  delays  can  degrade  a  unit’s  mission 
effectiveness,  but  their  impact  is  nothing  compared  to  the  potential  fallout  when  valuable 
equipment,  or  much  worse  when  personnel,  are  struck  by  lightning.  As  such,  determining  how 
far  naturally  occurring  lightning  normally  travels  from  thunderstorms  can  provide  insight  to 
decision  makers  concerning  in-flight  and  ground  safety  measures. 

3D  lightning  data  from  the  Kennedy  Space  Center  was  merged  with  archived  weather 
radar  data  from  Melbourne,  Florida.  To  analyze  the  radar  characteristics  of  lightning,  the  radar 
data  was  interpolated  to  a  3D  grid  of  reflectivity  to  permit  direct  extraction  of  reflectivity  values. 
More  than  19,000  lightning  flashes  were  analyzed  to  resolve  the  composite  reflectivity  of  the 
flash  origin  and  to  determine  the  horizontal  distance  of  the  flash  origin  from  the  nearest  radar 
reflectivity  core — defined  as  a  radar  reflectivity  factor  (dBZ)  of  greater  than  40  dBZ.  More  than 
8,500  flashes  were  used  for  similar  base  reflectivity  computations. 

95%  of  the  flash  origins  either  had  a  composite  reflectivity  of  greater  than  40  dBZ  or 
were  within  3  km  of  the  nearest  40-dBZ  radar  echo.  95%  of  the  flash  origins  had  a  base 
reflectivity  of  greater  than  40  dBZ  or  were  within  6  km  of  the  nearest  40-dBZ  echo.  In  addition, 
99%  of  the  flashes  traveled  less  than  30  km  from  the  flash  origin,  and  less  than  21  km  from  the 
nearest  40-dBZ  echo.  Based  upon  these  results,  it  should  be  feasible  to  suggest  lightning 
avoidance  criteria  based  upon  the  radar  reflectivity  displayed  by  ground  or  airborne  radars. 
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SYNTHESIS  OF  3-DIMENSIONAL  LIGHTNING  DATA  AND  WEATHER 


RADAR  DATA  TO  DETERMINE  THE  DISTANCE  THAT  NATURALLY 
OCCURRING  LIGHTNING  TRAVELS  FROM  THUNDERSTORMS 


I.  Introduction 


1.1.  Motivation 

Lightning  is  a  common  natural  phenomenon  that  can  adversely  affect  Air  Force 
ground  and  aerospace  operations.  The  impact  that  lightning  has  on  mission  effectiveness 
can  range  from  mild  to  the  extreme.  A  lightning-producing  thunderstorm  approaching  a 
base,  prompting  the  Base  Weather  Station  (BWS)  to  issue  a  weather  warning,  will  cause 
all  maintenance  activities  on  the  flight  line  to  be  halted  immediately  as  personnel  take 
shelter  (Department  of  the  Air  Force  1997).  A  delay  in  the  maintenance  schedule  may  be 
a  mere  annoyance;  it  could,  however,  have  a  very  significant  impact  on  overall  mission 
capability.  Even  a  severe  delay  in  maintenance  and  flight  operations  that  degrades  a 
unit’s  effectiveness  is  insignificant  when  compared  to  the  potential  lethality — to  both 
personnel  and  valuable  equipment — of  actually  being  struck  by  lightning. 

An  aircraft  struck  by  lightning  may  incur  anything  from  minimal  damage  to  the 
skin  of  the  aircraft  to  catastrophic  system  failure.  Given  the  nature  of  modern  military 
aircraft  design,  especially  those  airframes  with  stealth  characteristics  where  the  skin  is 
made  up  of  composite  materials,  even  seemingly  modest  damage  to  the  aircraft’s  outer 
surface  can  be  extremely  expensive  to  repair.  Aircraft  parked  on  the  flight  line  and  the 
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personnel  that  maintain  them,  are  in  jeopardy  of  being  struck  by  cloud-to-ground 
lightning.  Once  airborne,  however,  the  threat  of  lightning  strikes  also  includes  the  much 
more  prevalent  cloud  discharges  that  never  reach  the  ground.  The  desire  for  rather  liberal 
lightning  avoidance  flight  restrictions  to  allow  for  more  flight  hours — especially  in  the 
summer  months  when  afternoon  thunderstorms  are  present  across  much  of  the  southern 
United  States — must  be  weighed  against  the  concerns  for  the  safety  of  the  crewmembers, 
passengers,  and  valuable  cargo. 

A  key  element  in  coming  up  with  recommendations  for  aircraft  in-flight  lightning 
avoidance  is  determining  the  distance  that  naturally  occurring  lightning  travels  from 
thunderstonn  radar  echoes.  Most  modern  military  aircraft  have  onboard  radars  that  are 
capable  of  interrogating  thunderstorms.  A  study  of  the  radar  characteristics  of  lightning 
source  regions,  when  coupled  with  information  about  the  extent  that  naturally  occurring 
travels,  could,  potentially,  provide  the  basis  for  improved  guidance  on  lightning 
avoidance.  The  same  holds  true  for  verification  criterion  for  issuing  and  canceling 
lightning  warnings  at  Air  Force  installations;  the  distance  that  cloud-to-ground  lightning 
normally  travels  from  its  source  to  the  ground  strike  location  is  of  particular  interest  in 
examining  this  radius.  If  the  distance  that  cloud-to-ground  lightning  travels  can  then  be 
correlated  with  a  radar  echo  signature  of  the  source,  better  guidance  for  BWS  personnel 
may  be  possible. 

1.2.  Problem  and  Importance 

Personnel  struck  by  lightning  can  be  severely  injured,  or  even  killed;  no  asset  in 
the  Air  Force  inventory  is  more  precious  than  the  people  that  make  up  the  force.  In  a 
tragic  event  that  took  place  at  Hurlburt  Field,  Florida  on  29  April  1996,  a  young  ainnan 
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lost  his  life  after  being  struck  by  lightning  while  maintaining  an  AC-130H  aircraft 
(Bauman  1998).  At  0804  CDT  the  BWS  issued  an  advisory  for  observed  lightning  within 
3  NM.  The  advisory  remained  in  effect  for  the  next  hour  and  twenty  minutes  with  no 
further  lightning  observed  within  3  NM  of  the  airfield  during  that  time.  At  0930  CDT  the 
advisory  was  cancelled,  with  an  indication  that  it  may  need  to  be  reissued  within  the  next 
30  minutes.  Immediately  after  the  advisory  was  cancelled,  a  maintenance  crew  was 
dispatched  to  resume  a  training  class  on  AC-130H  tire  replacement  procedures.  At  0938 
CDT,  while  one  of  the  ainnan  was  in  the  wheel  well  of  the  AC- 13  OH,  a  bolt  of  lightning 
struck  the  aircraft.  Ten  personnel  were  injured,  and  the  airman  that  was  in  the  wheel  well 
was  killed.  Air  traffic  controllers  estimated  that  the  thunderstorm  that  caused  the 
lightning  was  about  5-7  NM  south  of  the  airfield. 

As  a  result  of  the  events  of  29  April  1996,  weather  warnings  for  lightning  at  all 
Air  Force  installations  are  to  be  issued  when  lightning  is  observed  within  5  NM 
(Department  of  the  Air  Force  1998).  According  to  this  Air  Force  Manual  (AFM),  the 
warning  is  to  stay  in  effect  until  the,  “thunderstorms  have  passed  beyond  the  area  covered 
by  the  warning.”  Perhaps  nothing  could  have  prevented  the  tragedy  that  occurred  that 
day;  the  investigation  found  that  all  parties  involved — the  BWS,  maintenance,  and 
medical  personnel — had  done  everything  right  based  upon  the  information  available  to 
them  (Bauman  1998).  But,  is  it  possible  that  even  the  5-NM  criterion — which  is  declared 
in  AFM  15-125  (1998)  to  be  the  minimum  distance  to  be  used  to  trigger  a  lightning 
warning  to  be  issued  or  cancelled — is  not  adequate?  Also,  when  trying  to  determine 
when  the  thunderstorm  has  moved  out  of  the  area  to  warrant  canceling  a  warning,  what 
should  the  BWS  personnel  use  to  determine  how  far  away  the  thunderstonn  is?  Can  a 
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rule-of-thumb  that  uses  radar  information  be  ascertained  that  will  take  some  of  the 


uncertainty  out  of  this  process?  But,  cloud-to-ground  lightning  is  not  the  only  concern. 

The  System  Program  Office  (SPO)  for  the  C-17  Globemaster  III  requested 
information  about  how  far  lightning  travels  from  thunderstonns  so  better  guidance  on 
lightning  avoidance  could  be  given  to  aircrews.  It  is  estimated  that  an  Air  Force  C-17  is 
struck  by  lightning  approximately  once  every  4,400  hours  of  operation  (C-17  TIM  Brief 
2001).  Information  about  lightning  avoidance  is,  however,  of  general  interest  to  the 
entire  U.S.  Air  Force  flying  community.  Answering  the  questions  posed  in  the  previous 
paragraph  is  the  goal  of  this  work  along  with  two  other  studies  being  accomplished  this 
year  at  AFIT — the  other  theses  are  by  Captain  Todd  McNamara  and  Captain  David 
Vollmer.  When  the  results  of  this  work  and  the  other  two  projects  are  combined,  it 
should  provide  better  guidance  to  decision  makers  about  both  the  cloud-to-ground 
lightning  safety  issue  and  in-flight  lightning  avoidance  criteria  for  military  aviation 
assets. 


1.3.  Purpose  and  Scope  of  Work 

The  purpose  of  this  research  is  to  examine  the  radar  reflectivity  signatures  of 
lightning  flashes  to  determine  if  it  is  possible  to  establish  guidance  for  aircraft  lightning 
avoidance  and  improved  criteria  for  issuing/canceling  lightning  warnings  based  upon 
these  radar  signatures.  For  this  study,  the  thresholds  of  radar  reflectivity  factor  displayed 
by  the  C-17’s  radar  system  are  used  to  define  a  critical  reflectivity  value  (40  dBZ)  for 
identification  of  thunderstorm  reflectivity  cores.  This  allows  an  analysis  of  the  radar 
reflectivity  characteristics  of  lightning  flash  origins  based  upon  ground-based  weather 
radar  observations  to  be  applicable  to  what  an  aircrew  member  would  see  on  their  radar 
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display.  The  fusion  of  these  lightning  base  reflectivity  signatures  with  detenninations  of 
the  distances  lightning  travels  from  the  origin  points,  may  aid  in  developing  a  rule-of- 
thumb  for  aircraft  lightning  avoidance.  In  addition,  the  lightning  flash  origin  composite 
radar  reflectivity  signature,  when  coupled  with  Captain  McNamara’s  results  about 
distances  of  cloud-to-ground  lightning,  can  provide  valuable  information  about  lightning 
warning  criteria. 

Three-dimensional  lightning  data  from  the  Lightning  Detection  and  Ranging 
(LDAR)  system  at  the  Kennedy  Space  Center  (KSC),  in  conjunction  with  the  weather 
radar  coverage  of  the  KSC  area  provided  by  the  National  Weather  Service’s  (NWS) 
Weather  Surveillance  Radar  -  1988  Doppler  (WSR-88D)  at  Melbourne,  Florida,  makes 
an  examination  of  lightning  phenomenon  in  the  KSC  area  a  natural  choice  for  this  task. 
Raw  LDAR  data  sets  are  archived  and  available  for  download  from  the  Global 
Hydrology  Resource  Center,  and  WSR-88D  data  are  available  in  archived  format  on 
8mm  data  tape  from  the  National  Climatic  Data  Center  (NCDC).  The  nature  of  working 
with  archived  radar  data  makes  it  unfeasible  to  conduct  a  broad  survey  that  mergers  all 
available  LDAR  and  radar  data.  As  such,  case  studies  are  selected  that  provide  data  for 
two  differing  weather  regimes  that  impact  the  KSC  area.  The  geographic  restriction 
imposed  by  the  fact  that  the  only  3D  lightning  data  readily  available  are  from  the  KSC,  is 
a  major  limiting  factor  on  the  scope  of  this  research. 

Another  limiting  factor  is  that  only  naturally  occurring  lightning  is  being 
considered.  In  an  article  that  appeared  on  the  web-based  magazine,  Aerospace 
Engineering  Online,  Lalande  et  al.  (1995)  assert  that  about  90%  of  all  aircraft  lightning 
strikes  are  cases  of  triggered  lightning,  rather  than  naturally  occurring  lightning  that  is 
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intercepted  by  the  aircraft.  This  triggered  lightning  occurs  when  an  aircraft  flies  into  a 
region  of  a  thunderstorm  where  a  very  intense  electrostatic  field — in  the  range  of  50  - 
100  kV/m — is  present.  The  fact  that  the  intent  of  this  study  is  to  provide  better  guidance 
on  thunderstorm  avoidance  mitigates  the  impact  of  this  constraint. 

1.4.  Summary  of  Results 

More  than  19,000  lightning  flashes  were  merged  with  weather  radar  data  to 
determine  the  typical  composite  radar  characteristics  of  lightning  flash  origin  points.  The 
radar  reflectivity  factor  (dBZ)  used  to  identify  the  reflectivity  cores  of  thunderstorms  is 
40  dBZ.  95%  of  all  the  flash  origins  were  either  within  a  40-dBZ  echo,  or  were  less  than 
3  km  from  the  edge  of  the  nearest  40-dBZ  echo.  For  base  reflectivity  analysis,  it  was 
found  that  95%  of  the  more  than  8,500  flash  origins  considered  were  less  than  6  km  from 
the  nearest  40-dBZ  reflectivity  core.  In  order  to  provide  guidance  on  lightning  avoidance 
based  upon  radar  echoes  for  weather  or  aircrew  personnel,  information  about  the  extent 
of  lightning  from  the  flash  origin  points,  and  from  the  radar  reflectivity  cores,  was  also 
examined. 

The  maximum  horizontal  distance  for  each  flash,  measured  from  the  flash  origin 
point  to  each  subsequent  point  in  the  lightning  flash,  of  the  19,000+  lightning  flashes  in 
the  composite  reflectivity  dataset  was  calculated.  99%  of  the  flashes  traveled  less  than  30 
km  from  their  origin,  and  95%  extended  less  than  19  km  from  the  flash  origin.  In 
addition  to  these  horizontal  distance  detenninations,  the  maximum  flash  distance  from  a 
40-dBZ  echo,  which  represents  the  actual  distance  measured  from  each  point  in  a  flash  to 
the  nearest  40-dBZ  echo  in  three  dimensions,  for  the  8,5 15  flashes  in  the  base  reflectivity 
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dataset  was  also  computed.  99%  of  these  flashes  traveled  no  more  than  2 1  km  from  the 
nearest  40-dBZ  echo. 

Combining  the  flash  origin  radar  characteristics  with  information  about  the 
overall  extent  of  the  lightning  from  the  origin  provides  the  data  necessary  to  suggest 
potential  lightning  avoidance  and  lightning  warning  criteria  based  upon  radar  echoes.  For 
example,  it  may  be  possible  to  suggest  that  weather  warnings  for  lightning  within  five 
nautical  miles  of  an  Air  Force  installation  could  be  issued  when  the  40-dBZ  composite 
reflectivity  echo  of  a  lightning-producing  thunderstorm  comes  within  7  NM  of  the 
advisory  area.  This  could  add  to  the  overall  safety  of  base  personnel  by  not  waiting  to 
issue  an  advisory  until  lightning  is  actually  observed  within  5  NM. 

The  data  also  suggests  that  a  possible  lightning  avoidance  rule  for  aircraft  would 
be  to  stay  at  least  36  km  (or  about  20  NM)  away  from  the  40-dBZ  radar  reflectivity  cores 
in  thunderstorms.  Also,  much  less  restrictive  avoidance  criteria  might  be  suggested  by 
basing  the  rule  on  the  finding  that  99%  of  lightning  flashes  traveled  no  more  than  2 1  km 
from  the  nearest  reflectivity  core.  At  the  very  least,  this  may  show  that  the  20  NM 
avoidance  rule  would,  indeed,  be  adequate. 

1.5.  Thesis  Organization 

This  initial  chapter  served  as  a  brief  introduction  to  the  research  topic  and  its 
importance  to  the  Air  Force.  The  next  chapter  is  designed  to  allow  the  reader  to  gain 
insight  into  some  necessary  background  information.  A  very  brief  discussion  of  lightning 
basics  is  presented,  followed  by  information  about  the  LDAR  system  at  the  KSC.  The 
radar  coverage  over  the  KSC  area  is  also  detailed.  Chapter  three  describes  the 
methodologies  employed  to  process  the  LDAR  and  radar  data  and  to  merge  the  resulting 
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data  sets.  A  brief  explanation  of  how  case  study  days  were  chosen  is  presented  as  well. 
Analyses  of  the  findings  of  this  research  are  offered  in  the  fourth  chapter.  The  final 
chapter  outlines  the  conclusions  reached  and  suggests  possible  future  research  that  could 
further  this  project. 
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II.  Background 


2.1.  Thunderstorm  Electrical  Structure 

The  conceptual  model  of  the  electrical  charge  distributions  in  thunderstorms  has 
evolved  as  better  measurement  techniques  have  been  developed.  The  classical  tripole 
model  of  thunderstorm  charge  distribution  was  developed  in  the  1920s  and  1930s  based 
upon  ground-based  electric  field  measurements  (Uman  and  Krider  1989).  Figure  1 
depicts  the  classic  tripole  model,  which  consists  of  a  main  negatively  charged  region 
below  the  main  (upper)  positively  charged  region  plus  a  lower  positively  charged  region. 


Figure  1.  Classic  tripole  model  of  charge  distribution.  Tripole  model  consists  of  a  main  negative  region 
below  a  main  (upper)  positively  charged  region,  plus  a  weak,  lower,  positive  region,  (adapted  from 

Mcllveen  1992). 
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A  more  detailed  conceptual  model,  based  upon  balloon  soundings  of  the  electrical 
structure  of  thunderstorms  from  three  different  types  of  convection:  organized  multicell, 
isolated  super-cell,  and  multicell  airmass,  has  recently  been  suggested  (Stoltzenburg  et  al. 
1988).  The  charge  distributions  in  this  new  model  are  more  complex  than  the  classic 
tripole  model,  however,  there  are  traits  that  are  common  to  all  three  types  of  convection. 
Figure  2  shows  this  new  paradigm  with  four  charged  regions  in  the  vertical  column 
around  the  updraft  and  six  charged  regions  outside  of  the  updraft.  It  is  asserted  that  the 
classic  tripole  model  may  be  imbedded  in  these  charge  regions.  With  this  model  in  mind, 
we  can  now  examine  the  lightning  discharge. 


Figure  2.  Modified  conceptual  model  of  charge  distribution.  The  modified  model  of  charge  distribution 
shows  four  charged  regions  in  the  updraft  region  of  the  storm  and  six  charged  regions  outside  the  updraft 

region,  (adapted  from  Stoltzenburg  et  al.  1998). 
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2.2.  The  Lightning  Discharge  Process 

Uman  and  Krider  (1989)  define  lightning  as,  “a  transient,  high-current  discharge 
with  a  path  length  measured  in  kilometers.”  Lightning  is  classified  in  four  basic  ways: 

(1)  lightning  that  occurs  wholly  within  the  cloud,  (2)  cloud-to-cloud  discharges,  (3) 
cloud-to-air  discharges,  and  (4)  cloud-to-ground  lightning  (CG).  These  first  three  types 
of  discharges  are  collectively  known  as  cloud  discharges  as  they  never  actually  reach  the 
ground.  It  is  estimated  that  for  every  CG  discharge  in  the  continental  United  States,  there 
are  almost  three  cloud  discharges  (Boccippio  et  al.  2000).  However,  much  more  is 
known  about  the  processes  that  take  place  during  CG  lightning,  so  we’ll  first  examine  CG 
basics  to  get  a  better  understanding  of  what  may  be  occurring  in  cloud  discharges. 

2.2.1.  CG  Lightning.  Most  of  the  research  accomplished  to  date  has  focused 
primarily  on  CG  lightning.  Two  of  the  primary  reasons  are  that  it  poses  a  much  greater 
threat  to  human  life  and  property,  and  it  is  also  easier  to  study  using  optical  techniques 
(Uman  and  Krider  1989).  Lightning  discharges  between  cloud  and  Earth  can  be  either 
positive  or  negative — as  determined  by  the  dominant  charge  present  at  the  source  region. 
CG  discharges  of  either  polarity  can  be  initiated  from  the  cloud  downward,  or  much  less 
frequently  from  the  ground  upward.  Uman  and  Krider  (1989)  point  out  that  negative 
downward-propagating  CG  flashes  account  for  about  90%  of  ah  CG  lightning  worldwide. 

A  negative  CG  flash  can  lower  tens  of  coulombs  of  negative  electrical  charge  to 
Earth  and  last  for  about  half  a  second  (Uman  and  Krider  1989).  A  single  lightning  flash 
can  have  several  high-current  pulses  called  strokes.  These  strokes  occur  on  order  of  only 
a  millisecond  with  a  slight  delay  of  tens  of  milliseconds  between  strokes.  In  order  for  a 
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stroke  to  occur,  a  pathway  must  be  present.  The  channel  that  transports  the  charge  is 
called  a  stepped  leader. 

When  the  charged  region  in  part  of  a  cloud  reaches  a  critical  threshold,  a 
preliminary  breakdown  occurs  and  a  stepped  leader  is  initiated  (Uman  and  Krider  1989). 
These  leader  steps  are  typically  about  1  ps  in  duration,  50  m  in  length,  and  have  a  delay 
between  steps  of  20  to  50  ps.  As  the  stepped  leader  nears  the  ground,  the  electric  field  on 
the  ground  builds  until  the  breakdown  strength  of  the  air  is  exceeded.  When  this 
happens,  upward-moving  discharges  are  initiated  from  sharp  objects  on  the  ground  or 
irregularities  on  the  surface  (Uman  and  Krider  1989). 

When  one  of  these  upward-moving  discharges  meets  the  downward-moving 
stepped  leader,  the  leader  is  effectively  connected  to  ground  potential  and  an  ionizing 
wave  of  ground  potential  propagates  up  the  ionized  leader  channel  (Uman  and  Krider 
1989).  This  is  the  first  return  stroke,  which  typically  lasts  on  order  of  100  ps.  The  leader 
channel  is  heated  to  a  peak  temperature  of  about  30,000  K  due  to  the  rapid  release  of 
energy  (Uman  and  Krider  1989).  As  a  result  of  the  temperature  increase,  the  channel 
expands  and  causes  a  compression  wave  that  becomes  thunder.  If  enough  cloud  charge  is 
still  available  after  the  first  return  stroke,  a  dart  leader  can  propagate  down  the  original 
path  and  trigger  further  return  strokes. 

The  peak  current  in  a  positive  CG  flash  is  typically  much  greater  than  that  of  a 
negative  CG  flash,  but  much  less  is  known  about  the  exact  nature  of  positive  CG  flashes 
(Uman  and  Krider  1989).  The  stepped-leaders  in  a  positive  CG  discharge  are  normally 
not  as  discretely  stepped  as  they  are  in  a  negative  flash.  Positive  flashes  normally  only 
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have  one  return  stroke  and  positive  flashes  are  much  more  common  in  winter  than  in 
summer  months  (Uman  and  Krider  1989). 

2.2.2.  Cloud  Discharges.  Until  recently,  there  was  no  reliable  way  to 
understand  the  structure  of  cloud  discharges,  but  the  development  of  three-dimensional 
lightning  mapping  systems  has  opened  the  door  to  a  better  understanding  of  what  is 
occurring  within  the  cloud  (Rison  et  al.  1999).  Examination  of  data  from  these  systems 
has  confirmed  that,  normally,  a  bipolar  breakdown  occurs  between  the  main  negative  and 
the  upper  positively  charged  regions  of  a  cloud.  Cloud  discharges  can  move  tens  of 
coulombs  of  charge  over  a  distance  of  5  to  10  km,  or  more  (Uman  and  Krider  1989). 

Both  CG  flashes  and  cloud  discharges  release  electromagnetic  energy  as  they  propagate 
through  the  atmosphere;  these  3D  lightning  detection  systems  take  advantage  of  that  fact 
to  aid  in  locating  where  these  events  are  taking  place. 

2.3.  Lightning  Detection  and  Ranging  (LDAR) 

The  LDAR  system  was  developed  primarily  by  Carl  Lennon,  a  former  National 
Aeronautical  and  Space  Administration  (NASA)  engineer,  in  the  mid-1970’s  in  support 
of  lightning  research  efforts  at  the  KSC  in  Llorida  (Starr  et  al.  1998).  The  system  consists 
of  seven  VHL  antennas  separated  by  5-10  km  located  near  the  KSC  launch  facilities 
(Ligure  3).  Pulses  of  VHP  energy  emitted  during  the  stepped  leader  process  of  a 
lightning  event  are  located  in  east/west,  north/south,  and  height  coordinates  from  the 
central  site.  It  locates  these  points  by  determining  the  relative  difference  in  the  time  of 
arrival  (TOA)  of  a  VHP  pulse  at  several  antennas  in  the  array.  The  central  site  antenna  is 
the  critical  element  of  this  system  architecture;  it  must  detect  a  signal  for  any  processing 
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to  occur  (Starr  et  al.  1998).  To  understand  how  the  system  determines  the  location  of  an 
event,  we  will  examine  the  data  flow  in  the  system. 


Figure  3.  KSC  LDAR  Antenna  Locations.  This  map  of  the  KSC  area  shows  the  relative  locations  of  the 
seven  antennas  in  the  LDAR  array.  The  antennas  are  seperated  by  about  5-10  km  and  are  spread  out 
about  the  LDAR  central  site — site  0  on  the  map.  (Adapted  from  Starr  et  al.,  1998). 


2.3.1.  Data  Flow  in  LDAR  System.  The  RF  energy  that  the  system  detects  is  in 
the  VHF  region  centered  at  63  MHz,  which  is  in  the  middle  of  the  spectrum  allocated  to 
television  channel  3  (Lennon  and  Maier  1991).  This  frequency  was  chosen  not  only 
because  it  is  within  the  spectrum  of  pulse  energy  emitted  by  lightning  processes,  but  also 
because  there  was  no  local  channel  3  operating  in  the  KSC  area  when  the  system  was 
designed.  When  the  central  site  detects  an  RF  pulse  that  exceeds  a  certain  threshold,  the 
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system  is  triggered  and  the  remote  antennas  transmit  time  of  arrival  data  to  the  central 
site  (Lennon  and  Maier  1991). 

The  same  pulse  of  RF  energy  detected  by  the  central  site  may  actually  arrive  at 
one,  or  more,  of  the  remote  antennas  before  being  detected  by  the  central  site.  The 
processing  that  takes  place  at  the  remote  sensor  sites,  however,  ensures  that  the  central 
site  will  receive  the  direct  signal  before  any  of  the  timing  data  is  received  from  the 
remote  sites.  When  a  detected  event  triggers  the  system,  a  100  (is  data  analysis  period 
begins  (Murphy  et  al.  2000).  Once  the  data  analysis  period  ends,  the  relative  TOA  of  the 
pulse  at  the  remote  antennas  is  calculated  and  the  time  difference  is  used  to  determine  the 
position  of  the  event.  This  location  process  involves  hyperbolic  triangulation  (Rustan  et 
al.  1980).  The  data  are  then  sent  to  a  display  workstation  for  graphical  display  and  are 
also  tagged  with  the  appropriate  position  and  timing  data  and  cataloged  digitally.  With 
this  basic  understanding  of  how  the  LDAR  system  detects  and  locates  VHF  pulses 
emitted  by  the  lightning  process,  it’s  important  to  gain  some  insight  into  just  how 
accurate  this  location  is. 

2.3.2.  Accuracy  of  LDAR  Data.  The  accuracy  of  LDAR  data  is  a  function  of 
the  range  from  the  central  site  and  the  altitude  of  the  event  (Murphy  et  al.  2000).  Most  of 
the  altitude  errors  are  linked  to  the  fact  that  all  LDAR  elevation  calculations  are  based 
upon  a  flat  plane  earth  and  do  not  account  for  curvature  of  the  Earth — although  these 
curvature  errors  are  only  significant  outside  of  about  100  km  range  from  the  LDAR 
location  (Boccippio  et  al.  2001).  The  range  error  is  the  paramount  accuracy  issue  with 
LDAR  data.  Maier  et  al.  (1995)  found  the  median  range  error  to  be  about  1km  location 
error  at  a  40  km  range  from  the  LDAR  central  site;  this  was  determined  by  using  a  signal 
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generator  aboard  an  aircraft  and  comparing  the  known  aircraft  locations  with  LDAR 
derived  locations.  One  of  the  primary  causes  of  the  range  inaccuracy  stems  from  a 
difficulty  in  precisely  detennining  the  TOA  of  the  peak  of  a  signal  in  a  pulse  of  RF 
energy  (Boccippio  et  al.  2001). 

2.4.  Radar  Coverage  of  the  Kennedy  Space  Center  Area 

The  WSR-88D  at  the  NWS  field  office  in  Melbourne,  Florida  provides  good 
weather  radar  coverage  of  the  KSC  area.  Their  radar  is  located  1.13  km  west  and  47.32 
km  south  of  the  LDAR  central  site.  The  height  of  the  radar  beam  over  the  KSC  area  can 
be  determined  (with  reasonable  accuracy)  using  the  following  equation  (Rinehart  1997): 

H  =  yjr2  +  R'2  +  2 rR'  sin  </>  -  R'  +  H0  (1) 

where  H  is  the  height  of  the  center  of  the  beam,  r  is  the  range  to  the  point  of  interest  from 
the  radar,  (j)  is  the  elevation  angle  in  degrees  of  the  radar  scan — 0.5  degrees  for  the 
lowest  WSR-88D  elevation  scan,  Ho  is  the  height  of  the  radar  antenna — about  30  m  for 
the  WSR-88D,  and  R’  is  the  effective  radius  of  the  earth  which  accounts  for  the  refractive 
index  gradient  along  the  path  of  propagation.  All  calculations  and  grid  interpolations 
used  in  this  project  are  based  upon  the  assumption  of  standard  refractivity  using 
R'  =  (4/3 )R  ,  where  R  is  the  radius  of  the  earth — assumed  to  be  constant  at  6374  km  for 
the  volume  coverage  pattern  (VCP)  and  beam  height  calculations  shown  here.  These 
assumptions  lead  to  an  estimated  central  beam  height  of  just  over  600  m  above  the  center 
of  the  LDAR  network  for  the  lowest  elevation  angle.  Figure  4  shows  the  relative 
position  of  the  WSR-88D  to  the  KSC  area. 
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Figure  4.  Map  of  Melbourne  WSR-88D  location.  This  map  shows  the  relative  position  of  the 
Melbourne,  FL  WSR-88D  to  the  KSC.  Range  rings  every  10  km  are  depicted.  The  LDAR  central  site  is 

located  just  less  than  50  km  north  of  the  radar  site. 


The  WSR-88D  operates  in  two  modes:  clear-air  mode  and  precipitation  mode. 
When  the  radar  is  operating  in  precipitation  mode  there  are  two  VCP’s  that  are  used: 
VCP-21  and  VCP-1 1.  A  radar  volume  created  in  VCP-21  mode  is  made  up  of  scans  at 
nine  elevations  (0.5°,  1.45°,  2.4°,  3.35°,  4.3°,  6.0°,  9.9°,  14.6°,  and  19.5°)  and  is 
accomplished  in  about  six  minutes.  VCP-1 1  mode  provides  scans  at  fourteen  elevation 
levels  (0.5°,  1.45°,  2.4°,  3.35°,  4.3°,  5.25°,  6.2°,  7.5°,  8.7°,  10.0°,  12.0°,  14.0°,  16.7°,  and 
19.5°)  and  is  completed  in  about  five  minutes.  Figure  5  shows  the  coverage  provided  by 
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the  two  precipitation  mode  VCP’s.  The  50  km  range  line  is  in  bold  to  serve  as  a 
reference  to  the  coverage  south  and  north  of  the  LDAR  central  site. 


Figure  5.  Radar  coverage  provided  by  VCP-11  and  VCP-21.  These  images  show  the  coverage  provided 
by  the  two  precipitation-mode  VCP’s  provided  by  the  WSR-88D.  The  gray  areas  represent  areas  of 
coverage  and  the  white  regions  represent  areas  with  no  coverage. 
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Figure  5  reveals  that  south  of  the  LDAR  central  site  there  is  very  sparse  coverage 
at  higher  altitudes.  In  fact,  just  20  km  south  of  the  LDAR  site,  there  is  no  radar  coverage 
above  10  km  and  very  limited  coverage  above  6  km;  this  limitation  in  radar  coverage  is 
very  significant  since  Boccippio  et  al.  (2001)  found  that  the  majority  of  LDAR  data 
points  occur  at  about  9  km  above  the  ground.  It  is  also  clear  that  north  of  the  LDAR  site, 
much  better  radar  coverage  of  the  upper  troposphere  is  provided  by  VCP-1 1  than  by 
VCP-21.  However,  even  with  this  improved  data  coverage,  there  are  gaps  in  the  radar 
coverage  at  higher  elevations. 
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III.  Research  Methodology 


This  section  chronicles  the  procedures  that  were  followed  and  the  logic  employed 
to  process  the  raw  LDAR  data  points  into  lightning  flashes,  transpose  WSR-88D  archive 
Level  II  data  to  a  3D  grid  of  radar  reflectivity  factor  values,  and  to  then  merge  these  two 
data  sets  to  extract  meaningful  data  about  the  radar  signatures  of  LDAR  data  points.  As 
mentioned  earlier,  this  project  is  one  of  three  current  projects  being  researched  by 
students  at  AFIT.  More  than  four  years  of  LDAR  data  were  processed,  though  only  ten 
days  of  lightning  and  radar  data  are  used  for  this  particular  study.  This  section  also 
outlines  how  days  were  selected  for  the  case  studies. 

3.1.  LDAR  Data  Point  Flash  Grouping 

The  first  task  to  be  accomplished  before  any  of  the  three  AFIT  projects  could  be 
undertaken  was  to  group  the  LDAR  data  points — which  essentially  represent  the 
locations  of  the  stepped  leaders  in  a  lightning  channel — into  individual  lightning  flashes. 
More  than  330  million  LDAR  data  points  had  to  be  grouped  into  lightning  flashes.  An 
extensive  amount  of  computing  time  was  required  to  process  the  massive  amount  of  raw 
LDAR  data  into  LDAR  flash-grouped  files.  The  largest  day  in  the  data  set  consisted  of 
over  eight  million  individual  data  points;  the  program  ran  for  almost  two  weeks  to 
process  that  day’s  lightning  activity  where  more  than  120,000  flashes  were  identified. 

The  flash-grouping  algorithm  used  by  NASA  and  described  by  Murphy  et  al. 
(2000)  was  used  as  the  model  for  grouping  individual  LDAR  data  points  into  lightning 
flashes.  NASA’s  flash-grouping  routines — which  are,  at  the  time  of  this  publication, 
available  on  the  NASA  public  web  site — are  written  in  the  C  programming  language. 
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This  code  was  closely  examined  and  used  as  a  blueprint  for  the  flash-grouping  algorithm 
employed  in  this  and  the  two  concurrent  studies  at  AFIT  (NASA  2001).  Appendix  A 
shows  the  code  of  the  AFIT  flash-grouping  program  written  for  the  Interactive  Data 
Language  (IDL)  environment.  The  algorithm  groups  LDAR  data  points  into  flashes 
based  upon  the  same  spatial  and  essentially  the  same  temporal  constraints  as  the  NASA 
algorithm. 

The  raw  LDAR  data  files  are  ASCII  text  files  that  contain  timing  and  location 
information;  the  time  is  recorded  to  the  microsecond  and  the  location  of  the  event  is 
given,  in  meters,  north/south  [x],  east/west  [y],  and  height  [z]  above  ground  level  on  a  flat 
plane  tangent  to  the  LDAR  central  site.  Data  points  from  a  calibration  signal  used  to 
ensure  proper  synchronization  of  the  system  are  included  in  the  LDAR  data  files  and  are 
easily  removed  by  the  flash-grouping  program.  The  location  of  this  signal  is  known  to 
within  meters,  so  a  simple  filter  is  employed  to  remove  any  signal  from  the  region 
immediately  around  the  calibration  signal’s  source.  Once  this  calibration  noise  is 
removed  from  the  data  set,  the  examination  of  the  remaining  data  points  begins. 

The  algorithm  detennines  the  following  information  about  each  point  in  an  LDAR 
data  file:  the  line  number,  flash  number,  branch  number,  branch  index  number,  and  the 
parent  point.  The  line  number  is  simply  detennined  by  sequentially  numbering  each  data 
point  in  the  file  and  is  used  to  identify  a  point.  The  flash  number  identifies  all  the  points 
that  are  part  of  the  same  lightning  flash;  LDAR  data  points  that  don’t  meet  the  spatial  and 
temporal  constraints  are  given  a  flash  number  of  negative  one  which  indicates  that  these 
points  are  not  part  of  any  lightning  flash.  The  branch  number  identifies  points  that  are 
detennined  to  be  part  of  the  same  branch  in  a  lightning  flash.  The  branch  index  number 
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indicates  the  point’s  sequential  position  in  a  branch.  Also,  the  first  point  in  a  branch  is 
given  a  parent  point  number  that  corresponds  to  the  line  number  of  the  point  in  the  flash 
that  is  closest  to  this  first  point  in  a  new  branch.  By  saving  the  preceding  information  for 
each  point  in  an  LDAR  data  file,  each  lightning  flash  can  be  reconstructed  without  any 
further  processing. 

To  identify  the  data  points  that  are  part  of  a  lightning  flash,  the  first  point  in  the 
LDAR  file  that  does  not  have  a  flash  number  yet  assigned  is  tentatively  considered  to  be 
the  origin  point  of  the  next  flash.  All  LDAR  data  points  that  occur  within  the  next  three 
seconds  of  this  potential  flash  origin  point,  that  have  not  been  identified  as  part  of  a 
previous  flash,  are  examined  to  determine  if  they  are  part  of  this  new  flash.  The  basic 
spatial  criterion  for  flash  grouping  is  5  km.  Due  to  the  LDAR  location  errors  described  in 
Chapter  2,  this  5-km  radius  is  expanded  into  an  ellipse  to  account  for  the  range  and 
azimuth  errors  in  locating  data  points  as  shown  in  Figure  6.  When  examining  a  point  to 
see  if  it  is  part  of  the  current  flash,  all  points  already  identified  as  part  of  the  current  flash 
are  checked  to  determine  if  any  of  those  points  fall  within  this  ellipse.  If  any  points  in  the 
current  flash  do  fall  in  this  region,  then  the  point  has  met  the  spatial  criteria  to  be 
considered  part  of  the  current  flash. 

When  a  point  has  met  the  spatial  criteria  to  be  included  in  a  flash,  the  difference 
in  the  end  time  of  the  flash — which  originally  is  the  time  of  the  origin  point  and  is  later 
updated  each  time  a  point  is  added,  since  the  LDAR  data  are  in  time  sequence  order — and 
the  time  of  the  point  is  checked.  If  there  is  more  than  a  0.5  second  difference  between  the 
time  of  the  point  being  checked  and  the  flash  end  time,  the  point  is  considered  to  be  too 
far  outside  the  time  constraints  and  the  flash  is  considered  terminated.  It  is  clear  that 
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multiple  lightning  flashes  can  (and  do)  occur  at  the  same  time  in  different  regions  around 
the  LDAR  system;  fortunately,  LDAR  is  capable  of  identifying  points  from  simultaneous 
flashes  in  multiple  locations.  This  half-second  constraint  allows  for  points  that  might  be 
missed  from  one  lightning  flash  when  there  is  a  virtually  simultaneous  flash  elsewhere. 


To  LDAR 
Central  Site 


Figure  6.  LDAR  Flash  Grouping  Ellipse  Diagram.  This  picture  shows  the  5  km  radius  used  as  the 
spatial  criterion  for  flash  grouping  and  the  orientation  of  the  ellipse  around  the  LDAR  data  point  (p).  The 
semi-minor  axis  (A)  is  oriented  perpendicular  to  a  line  connecting  the  point  p  to  the  LDAR  central  site. 
The  length  of  this  axis  is  the  5  km  radius  plus  a  one-degree  azimuthal  error.  The  semi-major  axis  (B) 
represents  the  5  km  radius  plus  a  range  location  error  factor  and  is  oriented  along  the  line  connecting  point 

p  to  the  LDAR  central  site. 


The  flashes  identified  by  the  program  are  further  grouped  into  branches  of 
lightning  again  using  a  spatial  and  temporal  test.  The  basic  spatial  proximity  for  a  point 
to  be  considered  part  of  an  existing  branch  is  that  the  point  be  within  1km  of  the  endpoint 
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of  an  existing  branch  in  this  flash — beyond  a  40  km  range  from  the  LDAR  central  site, 
this  1-km  radius  is  expanded  to  account  for  location  errors.  The  time  constraint  on 
including  a  point  in  a  branch  is  0.03  seconds  from  the  end  time  of  the  branch.  If  a  point 
is  found  to  meet  both  the  spatial  and  temporal  constraints  to  be  included  in  an  existing 
branch,  the  branch  number  of  the  point  is  set,  the  point  is  assigned  the  next  branch  index 
number,  and  the  end  point  and  end  time  for  this  branch  is  updated  with  this  new  branch 
point’s  information.  If  a  point  does  not  meet  the  temporal  and  distance  constraints,  it  is 
considered  to  be  the  first  point  in  a  new  branch;  the  nearest  point  in  the  flash  to  this  point 
is  then  designated  the  parent  point  of  this  new  branch. 

If  a  flash  is  found  that  contains  only  one  or  two  points,  it  is  not  considered  to  be  a 
valid  flash.  The  flash  number  of  the  origin  point  of  this  incomplete  flash  is  set  to 
negative  one,  while  the  other  points  in  the  incomplete  flash  are  reset  to  allow 
consideration  for  inclusion  in  another  flash.  Since  the  LDAR  data  files  are  ordered 
sequentially  by  time,  the  process  described  here  simply  repeats  until  all  points  have  either 
been  grouped  into  flashes  or  found  to  be  incoherent  noise.  After  the  program  executes, 
the  output  is  saved  to  a  text  file.  These  output  files  include  all  of  the  original  data  from 
the  valid — non-calibration — LDAR  data  points  for  each  day,  plus  the  flash  and  branch 
information  described  above.  Once  the  LDAR  flash  files  were  processed,  the  next  step 
was  to  select  days  for  the  case  study. 

3.2.  Case  Study  Selection 

The  nature  of  working  with  archived  radar  data  makes  it  impractical — if  not 
utterly  impossible — to  merge  several  years  of  lightning  data  with  radar  data.  Therefore, 
the  intent  was  to  select  several  days  of  thunderstorm  activity  near  the  KSC,  preferably 
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while  experiencing  the  influence  of  a  variety  of  weather  regimes.  The  possibility  of 
examining  lightning  and  radar  data  while  the  KSC  area  was  under  the  influence  of  either 
a  tropical  stonn  or  hurricane  was  examined,  but  no  available  days  of  the  LDAR  activity 
could  be  associated  with  the  archived  tracks  of  tropical  storms.  So,  two  types  of  weather 
making  conditions  were  selected  for  case  studies:  synoptic  and  airmass. 

3.2.1.  Synoptic  Cases.  The  term  synoptic  in  this  context  is  used  to  describe 
days  where  the  thunderstorm  activity  in  the  KSC  area  is  caused  primarily  by  the  passage 
of  a  synoptic-scale  weather  system  such  as  a  mid-latitude  cold  front  that  extends  down  to 
the  Florida  peninsula.  The  Bermuda  high  normally  dominates  during  the  summer  months 
and  prevents  most  cold  fronts  from  reaching  central  Florida  intact.  In  the  late -winter  and 
early-spring  months,  however,  cold  fronts  do  tend  to  influence  the  weather  in  Florida  and 
are  one  of  the  major  weather  producers  during  this  time.  The  methodology  used  to 
detennine  potential  days  for  case  study  of  synoptic  cases  involved  examining  the  size  of 
LDAR  flash  grouped  data  files  and  national  radar  mosaic  images. 

LDAR  data  files  from  1997  through  the  summer  of  2001  that  were  processed  with 
the  flash-grouping  algorithm  (see  Appendix  A)  were  sorted  by  size.  The  file  naming 
convention  used  for  the  LDAR  flash-grouped  files  allowed  easy  identification  of  the  date 
of  the  file.  Days  with  a  large  file  size — indicating  a  great  deal  of  lightning  activity 
around  the  KSC — that  occurred  in  the  late- winter/ early- spring  were  noted.  Next,  national 
radar  mosaic  images,  archived  on  the  NCDC  web  site,  were  examined  to  look  for 
signatures  of  either  a  squall  line  or  a  cold  front  moving  through  the  KSC  area  on  the  days 
of  significant  LDAR  activity.  One  synoptic  day  from  each  year  of  available  data  was 
then  selected.  Table  1  shows  quantitative  data  for  the  five  synoptic  days  that  were 


25 


chosen.  The  number  of  non-calibration  LDAR  data  points  and  the  number  of  lightning 
flashes  identified  by  the  flash-grouping  algorithm  for  each  day  are  shown.  The  average 
number  of  LDAR  data  points  per  lightning  flash  for  each  day  is  also  included.  It  should 
be  noted  that  data  included  in  this  table  cover  the  entire  day  and  not  just  the  time  when 
thunderstorm  activity  was  in  the  immediate  KSC  area.  For  these  five  days,  the  flash¬ 
grouping  program  processed  more  than  288,000  lightning  flashes,  consisting  of  more 
than  17  million  data  points.  This  equates  to  an  average  flash  rate  over  the  entire  domain 
of  the  LDAR  network  of  about  40  flashes  per  minute,  which  was  sustained  for  120  hours. 
The  extremely  large  influence  of  23  April  1997,  where  the  flash  rate  is  89  flashes  per 
minute  over  the  24-hour  period,  must  be  taken  into  account,  however.  The  other  four 
days  yield  an  average  flash  rate  of  almost  28  flashes  per  minute. 


Table  1.  Total  LDAR  Flash  Activity  on  Chosen  Synoptic  Days. 


Synoptic  Days 

Mean 

Date 

Number  of  LDAR  Points 

Number  of  Flashes 

Points /Flash 

April  23,  1997 

8,021,236 

128,392 

62.5 

February  23,  1998 

2,736,158 

45,500 

60.1 

February  28,  1999 

556,190 

10,439 

53.3 

March  31,  2000 

2,965,290 

26,673 

111.2 

March  29,  2001 

3,429,607 

77,238 

44.4 

Totals 

17,708,481 

288,242 

61.4 

3.2.2.  Airmass  Cases.  There  were  many  more  LDAR  data  files  that  indicated 
significant  lightning  activity  in  the  summer  months  and  that  would  have  potentially  been 
good  choices  for  inclusion  in  the  airmass  cases.  Most  late-spring  to  late-fall  days  in 
central  Florida  have  a  good  chance  of  airmass  thunderstorm  development;  the  area 
around  the  KSC  is  known  as  lightning  alley  for  this  very  reason.  The  larger  pool  of  days 
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with  significant  LDAR  activity  in  the  summer  time  frame  made  it  more  difficult  to  pick 
days  for  the  airmass  cases.  Again,  the  national  radar  mosaics  were  examined,  but  it  was 
much  more  difficult  to  identify  exactly  were  the  thunderstorms  were  occurring  in  relation 
to  the  KSC;  the  lack  of  linear  radar  echo  features — such  as  was  normally  present  in  the 
synoptic  events — made  the  selection  process  for  the  airmass  days  much  harder. 

Table  2  shows  the  LDAR  activity  for  the  five  chosen  airmass  case  study  days. 
Again,  the  data  here  are  for  the  entire  day  and  not  just  when  thunderstonns  were 
occurring  in  the  immediate  KSC  area.  The  flash-grouping  algorithm  grouped  more  than 
160,000  flashes,  which  were  made  up  of  more  than  1 1  million  data  points,  for  these  five 
days.  The  average  number  of  LDAR  data  points  per  lightning  flash  is  about  71, 
compared  to  an  average  of  about  61  for  the  synoptic  days.  Similarly,  the  average  flash 
rate  over  the  five-day  period — and  over  the  entire  LDAR  network  range — is  about  22 
flashes  per  minute;  this  is  significantly  less  than  the  40  flashes  per  minute  noted  in  the 
synoptic  cases,  but  not  that  much  different  than  the  flash  rate  of  about  28  flashes  per 
minute  for  the  synoptic  cases  when  the  23  April  1997  influence  is  accounted  for. 


Table  2.  Total  LDAR  Activity  on  Chosen  Airmass  Days. 


Airmass  Days 

Mean 

Date 

Number  of  LDAR  Points 

Number  of  Flashes 

Points  /Flash 

August  3,  1997 

2,275,840 

24,071 

94.5 

July  6,  1998 

3,901,975 

48,235 

80.9 

June  11,  1999 

2,749,853 

27,121 

101.4 

July  7,  2000 

2,201,607 

40,012 

55.0 

June  15,  2001 

606,171 

25,003 

24.2 

Totals 

11,735,446 

164,442 

71.4 
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3.3.  Radar  Data  Processing 

Once  the  case  study  days  were  chosen,  the  radar  data  for  each  identified  day  were 
ordered  from  NCDC  through  the  Air  Force  Combat  Climatology  Center.  The  WSR-88D 
archive  Level  II  data  arrived  on  8mm  data  tape.  The  National  Center  for  Atmospheric 
Research  (NCAR),  Mesoscale  and  Microscale  Meteorology  (MMM)  Division, 
developed  software  that  can  translate  this  WSR-88D  archive  Level  II  radar  data  to  a  3D 
Cartesian  grid  of  reflectivity  values. 

3.3.1.  Translation  to  3D  Grid.  The  Sorted  Position  Radar  Interpolation 
(SPRINT)  program  was  used  to  process  the  WSR-88D  archive  Level  II  data  files. 
SPRINT  creates  a  3D  data  set  of  floating-point  radar  reflectivity  factor  (in  dBZ)  values 
by  converting  reflectivity  data  stored  in  azimuth,  range,  and  elevation  angle  format  in  the 
NCDC  archive  Level  II  files  to  a  3D  Cartesian  grid  of  reflectivity.  A  standard 
atmosphere — using  a  4/3  effective  earth  radius  approximation — is  used  by  SPRINT  to 
detennine  the  height  above  ground  level  as  the  beam  propagates  away  from  the  radar  site. 
Defining  the  size  and  resolution  of  the  grid  is  the  critical  step  in  processing  the  archived 
radar  data. 

The  3D  grid  that  was  defined  has  201  points  in  the  x-direction  (east/west),  101 
grid  points  in  the  y-direction  (north/south),  and  34  layers  in  the  vertical,  with  a  horizontal 
and  vertical  resolution  of  500  m.  The  [x,y]  grid  location  closest  to  the  LDAR  central  site 
is  [100,0].  The  LDAR  central  site  is  located  about  1.13  km  east,  and  47.32  km  north,  of 
the  WSR-88D  location.  SPRINT  does  not  allow  the  exact  positioning  of  the  grid  to  this 
precision,  so  the  actual  position  of  the  [100,0]  grid  point  is  47.5  km  north,  and  1.0  km 
east,  of  the  radar;  the  grid  point  [100,0]  is  therefore  about  222  m  northwest  of  the  LDAR 
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central  site.  The  grid  covers  an  area  of  20,000  km  and  extends  50  km  west,  north,  and 
east  of  the  LDAR  central  site.  The  grid  also  provided  coverage  from  500  m  above 
ground  level  to  17km  in  the  vertical.  This  equates  to  a  volume  of  340,000  km  with 
690,234  data  points.  A  planar  view  of  this  radar  grid  over  a  map  background  is  shown  in 
Figure  7. 


Figure  7.  Planar  View  of  Radar  Grid.  There  are  201  points  in  the  x-direction  and  101  points  in  the  y- 
direction.  The  LDAR  central  site  is  located  just  southwest  of  the  point  [100,0].  The  lines  shown  are  drawn 
every  kilometer,  but  the  actual  resolution  of  the  grid  is  500  m.  Not  depicted  in  this  2-dimensional  drawing 
is  the  34  layers  in  the  vertical  that  also  provide  a  500  m  resolution  from  500  m  to  17  km  altitude. 


The  limits  of  the  radar  coverage  at  higher  altitudes  provided  by  the  two  WSR-88D 
precipitation  modes  (VCP21  and  VCP1 1)  south  of  the  LDAR  central  site  were  the 
primary  factor  considered  when  the  grid  was  defined.  Having  the  grid  only  extend  to  the 
north  of  the  LDAR  central  site  ensures  better  coverage  from  the  surface  to  17  km  (about 
55  Kft).  SPRINT  restricts  the  number  of  data  points  that  can  be  included  in  the  Cartesian 
reflectivity  grids  it  creates,  which  was  the  major  reason  for  the  choice  of  a  500  m  grid 
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resolution.  The  output  data  files  created  by  SPRINT  are  saved  in  a  fonnat  that  can 
essentially  only  be  read  by  another  program  developed  by  NCAR/MMM. 

The  Custom  Editing  and  Display  of  Reduced  Information  in  Cartesian  space 
(CEDRIC)  program  was  used  to  translate  the  SPRINT  output  files  to  a  more  useful 
format.  One  of  the  CEDRIC  options  is  to  convert  SPRINT  binary  output  data  files  to 
Network  Common  Data  Format  (NetCDF)  files.  NASA  and  the  Unidata  program  at  the 
University  Corporation  for  Atmospheric  Research  jointly  developed  the  NetCDF  as  a 
standard  way  of  storing  and  sharing  scientific  information.  IDL  has  built-in  routines  that 
allow  easy  access  to  data  structures  stored  in  NetCDF.  With  these  IDL  routines,  the  3D 
grid  of  reflectivity  values  can  easily  be  read  into  a  3D  array  of  floating  point  numbers.  In 
addition  to  the  reflectivity  information,  the  start  and  end  time  of  the  radar  volume  can 
easily  be  extracted  from  these  NetCDF  files. 

The  3D  array  of  dBZ  values  created  by  SPRINT/CEDRIC  is  then  used  to  create  a 
2D  array  of  composite  reflectivity.  Any  mention  in  this  study  to  the  base  reflectivity  of  a 
point  refers  to  the  3D  reflectivity  array,  and  references  to  composite  reflectivity  refer  to 
the  2D  data  set.  To  create  the  composite  reflectivity  array,  the  maximum  base  reflectivity 
value  in  the  vertical  column  for  each  [x,y]  location  is  assigned  as  the  composite 
reflectivity  value  for  that  [x,y]  grid  point. 

To  ensure  that  the  radar  volumes  created  with  this  process  were  valid,  sample 
base  and  composite  reflectivity  images  were  verified  by  comparing  planar  and  3D  views 
of  the  SPRINT/CEDRIC  processed  data  with  planar  views  of  composite  and  base 
reflectivity  created  using  the  WSR-88D  Algorithm  Testing  and  Display  System 
(WAT ADS)  software.  The  images  confirmed  that  the  interpolation  to  the  3D  grid  was 
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indeed  successful;  landmark  and  radar  signature  correlation  was  very  good.  There  were, 
however,  problems  encountered  when  running  SPRINT  and  there  were  also  some  data 
quality  issues  identified  when  looking  at  some  of  the  3D  radar  volumes. 

3.3.2.  Efficiency  and  Radar  Processing  Issues.  In  order  to  process  the 
WSR-88D  archive  Level  II  data,  the  data  files  first  had  to  be  dumped  from  the  8-mm  data 
tape  to  a  hard  drive  storage  device.  To  run  the  SPRINT  program,  a  script  file  was  created 
that  defined  the  location  and  resolution  of  the  desired  3D  grid  of  reflectivity  values. 
SPRINT  execution  was  quite  fast;  it  normally  took  less  than  30  seconds  to  process  a  radar 
volume.  The  CEDRIC  program  ran  even  faster,  normally  completing  execution  in  only  a 
few  seconds  per  radar  volume.  A  script  file  to  allow  the  processing  of  multiple  radar 
volumes  consecutively  with  one  call  to  the  SPRINT  executable  was  created.  It  would 
appear  to  complete  execution  normally.  A  companion  script  file  to  convert  the  multiple 
files  created  by  the  SPRINT  run  to  NetCDF  file  fonnat  with  a  single  call  to  CEDRIC  was 
created.  Upon  execution  of  this  script,  however,  a  problem  soon  became  evident. 

Not  all  of  the  WSR-88D  source  radar  volume  files  were  being  processed  by 
SPRINT.  SPRINT  would  periodically  encounter  a  situation  where,  for  an  unknown 
reason,  it  was  unable  to  match  the  volume  scan  data  to  the  3D  grid;  when  this  problem 
occurs,  SPRINT  would  simply  not  create  an  output  file  for  that  volume  and  would 
attempt  to  process  the  remaining  source  radar  volume  files.  When  the  CEDRIC  script 
file  tried  to  access  the  SPRINT  output  files,  there  would  be  missing  input  files  and 
CEDRIC  would  halt  and  cause  a  core  dump.  Eventually,  all  radar  volumes  were 
processed,  one  file  at  a  time;  this  became  a  very  tedious  procedure. 
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While  processing  the  raw  radar  volumes  with  SPRINT,  an  inventory  of  radar 
volumes  that  SPRINT  was  unable  to  process  was  kept.  In  fact,  14%  of  the  source  radar 
volume  files  (73  out  of  523)  could  not  be  processed  by  SPRINT.  No  detennination  of 
what  was  causing  the  malfunction  could  be  identified.  The  source  radar  volumes  were 
processed  and  viewed  with  WATADS  to  check  for  data  gaps  or  missing  elevation  levels, 
and  no  such  problems  with  the  source  data  could  be  found.  Later,  another  problem  with 
the  SPRINT  processing  was  discovered  when  viewing  the  3D  radar  volumes  using  IDL’s 
object-oriented  graphics  rendering  capabilities. 

Eventually,  all  450  radar  volume  files  that  were  successfully  processed — at  least 
those  not  causing  an  error — by  SPRINT  were  visually  examined.  Of  these  files,  42  were 
found  to  have  no  meaningful  radar  echoes;  this  doesn’t  mean  that  the  data  was  bad,  rather 
that  these  volumes  were  for  inactive  periods  where  there  was  no  lightning  activity.  This 
leaves  408  radar  volume  files  that  SPRINT  processed  and  CEDRIC  translated  without 
causing  an  error.  However,  visual  inspection  of  all  408  radar  volumes  found  that  27%  of 
these  files — 1 1 1  of  the  408 — had  significant  sections  of  data  missing  that  would  make 
even  a  composite  reflectivity  computation  unreliable — 73%  of  the  files  were,  at  least, 
partially  usable.  These  1 1 1  volumes  were  deemed  unusable  and  were  excluded  from  use 
for  any  reflectivity  or  distance  computations.  For  a  graphic  example  of  this  type  of  error, 
see  Figure  16  in  Appendix  B. 

Of  the  297  remaining  radar  volume  files,  about  70%  were  found  to  be  fully  usable 
and  were  used  for  both  composite  and  base  reflectivity  calculations,  and  distance 
computations.  The  other  30%  were  subjectively  deemed  to  be  partially  usable  radar 
volumes.  Partially  usable  radar  volumes  were  complete  enough  that  an  accurate 
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composite  reflectivity  image  grid  could  reasonably  be  created  from  the  3D  reflectivity 
grid,  but  too  much  data  were  missing  for  reliable  base  reflectivity  and  distance 
detennination.  Figure  17  in  Appendix  B  is  an  example  of  a  partially  usable  radar 
volume. 

3.4.  Merging  LDAR  and  Radar  Data 

Once  the  2D  and  3D  arrays  of  reflectivity  were  created,  it  was  possible  to  merge 
the  radar  and  lightning  data  sets.  Since  the  relative  location  of  the  LDAR  central  site  to 
the  point  [100,0]  in  the  reflectivity  grids  is  known,  a  simple  coordinate  transformation  is 
all  that  is  required  to  convert  the  LDAR  data  point  location  to  the  radar  reflectivity  grid. 
The  equations  used  for  this  coordinate  transform  are  as  follows: 
x  =  100  +  ((/7osAjf +  130)/500)  (2) 

y  =  {flashy  -180)/  500  (3) 

z  =  {flash.z  -  500)  /  500)  (4) 

where  the  x,  y,  and  z  location  of  the  LDAR  data  point  (in  meters)  is  denoted  by  flash.x, 
flashy ,  and  flash.z  respectively.  The  result  of  these  equations  is  the  x,  y,  and  z  grid 
location  of  the  LDAR  data  point  relative  to  the  3D  base  reflectivity  grid — or  the  2D 
composite  reflectivity  grid  if  only  the  x  and  y  locations  are  considered.  This  location  will 
normally  not  fall  exactly  on  a  grid  point,  so  optimal  interpolation  is  used  to  detennine  the 
radar  reflectivity  factor  for  each  LDAR  data  point  in  a  lightning  flash.  In  an  effort  to 
provide  aircrew  members  with  relevant  guidance  based  upon  what  they  can  expect  to 
observe  on  their  radar  displays,  the  distances  from  LDAR  data  points  to  critical 
reflectivity  thresholds  are  examined.  The  procedures  used  to  calculate  this  infonnation 
are  detailed  in  this  section. 
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3.4.1.  Determining  Reflectivity.  To  determine  the  radar  reflectivity  for  the 
points  in  LDAR  flashes,  the  LDAR  flash  data  file  for  the  day  being  examined  is  opened 
and  all  data  is  read  into  an  array  of  data  structures  with  the  timing,  location,  and 
flash/branch  information  for  each  data  point.  The  first  radar  volume  file  to  be  merged 
with  the  lightning  data  is  opened.  A  3D  base  reflectivity  array  and  a  2D  composite 
reflectivity  array  are  created  as  described  earlier,  and  the  start  time  and  end  time  of  the 
radar  volume  are  extracted  from  the  NetCDF  radar  volume  file.  Only  lightning  flashes 
that  occur  in  the  proper  time  window  and  whose  points  are  all  within  the  radar  reflectivity 
grid  are  considered. 

The  LDAR  data  array  is  searched  to  identify  the  flash  origin  points  that  are  within 
the  time  window  of  the  radar  volume  and  that  are  located  within  the  100  km  by  50  km 
radar  grid.  Once  the  flash  origins  are  identified,  each  flash  whose  origin  point  is  within 
the  grid  is  checked  to  see  if  all  points  in  the  flash  are,  too,  entirely  within  the  confines  of 
the  radar  grid.  Once  the  flashes  that  meet  the  time  and  space  criteria  are  identified,  the 
individual  data  points  of  each  flash  are  examined  to  determine  the  radar  reflectivity  factor 
by  using  the  coordinate  transfonnation  equations  and  optimal  interpolation.  Both  the  3D 
base  and  the  2D  composite  reflectivity  for  each  data  point  are  calculated.  This  process 
continues  for  all  of  the  identified  flashes  that  occur  within  the  temporal  bounds  of  the 
radar  volume  NetCDF  file — normally  a  span  of  five  to  six  minutes. 

The  next  radar  volume  file  is  then  opened  and  the  process  repeats  until  all  radar 
volumes  have  been  examined.  The  time  window  of  the  subsequent  radar  volumes  is 
taken  from  the  end  time  of  the  previous  radar  volume  scan  to  the  end  time  of  the  current 
radar  volume  scan  to  avoid  missing  any  flashes  that  originate  during  the  slight  delay 
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between  radar  volume  times.  If  there  are  missing  radar  volume  scans,  which  there 
commonly  are  due  to  the  problems  with  the  SPRINT  interpretation  of  some  radar 
volumes,  the  start  and  end  time  of  the  volume  is  once  again  used  and  some  of  the 
lightning  data  is  skipped  since  there  is  no  corresponding  radar  data. 

For  each  radar  volume  scan,  a  new  lightning  data  file  is  created  and  saved  with  all 
the  timing,  location,  flash/branch  infonnation  from  the  LDAR  flash  file,  plus  the 
reflectivity — both  3D  base  and  2D  composite — data  all  the  points  in  the  flashes  that 
occur  within  the  time  and  space  constraints  for  the  radar  volume.  Saving  the  data  for 
these  five  to  six  minute  windows,  and  with  a  much  smaller  spatial  region,  greatly  reduces 
the  individual  data  file  size  and  increases  the  speed  of  processing  the  data  for  subsequent 
analysis.  The  reflectivity  data  files  that  are  saved  during  this  step  can  be  directly 
compared  with  the  associated  radar  volume  to  determine  the  distances  of  these  LDAR 
data  points  from  significant  radar  echoes. 

3.4.2.  Determining  Distances  from  Radar  Echoes.  The  radar  display  on  the 
Air  Force’s  C-17  aircraft  shows  radar  echoes  with  a  three-color  scheme.  Radar  echoes 
greater  than  or  equal  to  40  dBZ  are  displayed  in  red,  while  reflectivity  values  between  30 
and  40  dBZ  are  portrayed  in  yellow,  and  20  to  30  dBZ  echoes  are  shown  in  green  (Lorenz 
2001).  Since  the  C-17  only  displays  reflectivity  data  in  three  colors,  the  40-dBZ 
threshold  was  chosen  as  the  best  reflectivity  value  to  represent  the  reflectivity  core  of  the 
thunderstorm  cells  that  lightning  distances  should  be  measured  from.  Interestingly, 
Gremillion  and  Orville  (1999)  identified  a  possible  relationship  between  the  detection  of 
the  40-dBZ  echo  at  the  level  of  the  -10°  C  temperature  and  CG  lightning  initiation  in 
airmass  thunderstorms  near  the  KSC.  Hoffert  and  Pearce  (1996)  also  noted  that  most 
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LDAR  activity  was  initiated  directly  above  the  reflectivity  cores  in  the  thunderstonns 
around  the  KSC  that  they  investigated — although  they  identified  the  reflectivity  core  as 
being  above  30  dBZ.  As  such,  the  distances  to  be  measured  will  be  from  the  nearest  40- 
dBZ  threshold  of  reflectivity. 

An  IDL  program  was  written  to  calculate  the  distance  of  LDAR  data  points  from 
these  radar  echo  cores.  The  program  opens  a  NetCDF  radar  volume  file  to  extract  the  3D 
base  reflectivity  volume  and  the  corresponding  LDAR  flash  reflectivity  file  with  the 
lightning  flash  data  points.  The  reflectivity  at  each  grid  point  in  the  3D  radar  array  is 
rounded  to  the  nearest  integer  dBZ  value  to  aid  in  identifying  the  location  of  the  threshold 
between  the  yellow  (30-40  dBZ)  region  of  a  C- 17  display  and  the  red  (40  dBZ  or 
higher)  echo.  A  2D  composite  reflectivity  grid  is  then  created  from  this  modified  3D 
base  reflectivity  volume. 

All  points  in  the  base  and  composite  reflectivity  arrays  with  a  radar  reflectivity 
value  greater  than  or  equal  to  40  dBZ  are  identified  and  the  grid  locations  of  these  points 
are  stored  in  an  array.  The  points  in  both  the  base  and  composite  reflectivity  arrays  that 
have  radar  reflectivity  values  of  between  30  -  39  dBZ  are  identified  as  well.  Again,  these 
thresholds  correspond  to  the  red  and  yellow  displays  of  the  C-17  radar,  respectively,  but 
would  also  correspond  to  a  WSR-88D  40-dBZ  threshold  on  a  composite  reflectivity 
display.  With  the  locations  of  theses  critical  radar  data  points  saved  in  appropriate  arrays, 
the  distance  to  the  nearest  of  these  points  from  any  LDAR  data  point  can  be  calculated. 
Recall  that  the  LDAR  data  files  used  by  this  program  contain  only  flashes  that  occur 
entirely  within  the  corresponding  radar  volume — based  upon  spatial  and  temporal 
constraints.  These  data  files  have  all  the  original  LDAR  data  (time  and  position  data), 


36 


plus  the  flash  grouping  data  (flash  number,  etc.),  as  well  as  the  radar  reflectivity  data 
(base  and  composite).  For  each  LDAR  data  point,  two  distances  are  calculated. 

The  first  distance  is  the  horizontal  distance  from  the  LDAR  data  point’s  [x,y] 
location  to  the  edge  of  the  nearest  40-dBZ  composite  reflectivity  threshold  (the 
red/yellow  line  on  a  C- 17  radar  display).  If  the  LDAR  data  point  has  a  composite 
reflectivity  value  greater  than  or  equal  to  40  dBZ,  the  distance  is  calculated,  in  meters,  to 
the  nearest  radar  grid  point  with  a  radar  reflectivity  of  between  30-39  dBZ  (yellow  on 
the  C-17  display).  This  distance  indicates  how  far  the  point  is  inside  the  red  radar  echo, 
as  displayed  by  the  C-17  radar.  If  the  LDAR  data  point  has  a  composite  reflectivity  value 
of  less  than  40  dBZ,  the  horizontal  distance  to  the  nearest  composite  reflectivity  grid 
point  of  40  dBZ  or  higher  is  calculated.  By  convention,  any  distance  that  represents  how 
far  an  LDAR  data  point  is  inside  a  given  radar  reflectivity  threshold  is  considered  to  be  a 
negative  distance;  a  positive  distance,  therefore,  indicates  how  far  outside  of  a  reflectivity 
threshold  a  point  is. 

The  second  distance  that  is  measured  is  a  3D  distance,  in  meters,  from  the  LDAR 
data  point’s  [x,y,z]  location  to  the  nearest  red/yellow  threshold  as  would  be  displayed  by 
the  C-17  radar.  Here,  if  a  point  has  a  base  reflectivity  of  greater  than  40  dBZ,  the 
distance  to  the  nearest  3D  radar  grid  location  with  a  reflectivity  of  between  30  -  39  dBZ 
is  calculated,  and  interpreted  as  a  negative  value.  For  LDAR  points  with  a  base 
reflectivity  of  less  than  40  dBZ,  the  distance  to  the  nearest  40  dBZ  or  higher  base 
reflectivity  location  is  calculated.  This  effectively  measures  the  distance  from  each  point 
in  the  LDAR  reflectivity  data  file  to  the  nearest  40-dBZ  line  on  a  radar  display.  One 
additional  constraint  is  placed  upon  flashes  to  be  considered  for  the  base  reflectivity 
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computations,  if  the  flash  origin  reflectivity  value  has  a  value  of  less  than  zero  (dBZ),  the 
flash  is  ignored.  The  reason  for  this  constraint  is  to  eliminate  the  influence  of  bad  data 
points  left  over  from  the  SPRINT  interpolation.  SPRINT  assigns  a  reflectivity  of -32768 
to  indicate  bad  data.  Radar  volumes  that  were  marginal  as  far  as  the  subjective  analysis 
of  whether  or  not  a  volume  was  usable  tend  to  have  numerous  LDAR  data  points  that 
return  a  reflectivity  value  of -32768.  The  conservative  approach  that  if  a  flash  origin  is 
being  influenced  by  corrupt  (or  missing,  due  to  the  gaps  in  the  particular  VCP)  data,  then 
any  inference  about  distances  would  be  suspect.  In  addition,  if  more  that  25%  of  the 
points  in  a  flash  were  bad  data,  no  base  reflectivity  based  distance  calculations  were 
accomplished,  again  to  avoid  data  corruption. 

The  net  result  of  this  constraint,  combined  with  the  elimination  of  the  27%  of  the 
processed  radar  volumes  that  were  too  corrupt  to  reliably  detennine  any  base  reflectivity 
distance  calculations,  is  that  the  final  sample  size  of  the  base  reflectivity  dataset  is  much 
smaller  than  the  final  composite  reflectivity  dataset.  Table  3  shows  the  breakdown  of  the 
lightning  activity  for  the  297  radar  volumes  that  are  being  processed  for  composite 
reflectivity  calculations.  These  radar  volumes  cover  a  time  span  of  approximately  25 
hours  of  thunderstonn  activity;  this  equates  to  a  sustained  flash  rate — only  within  the 
spatial  confines  of  the  defined  radar  grid — of  about  13  flashes  per  minute. 

Table  4  shows  the  same  information  for  the  limited  data  set  that  is  being 
considered  for  base  reflectivity  computations.  The  209  radar  volumes  that  were  deemed 
usable  for  base  reflectivity  considerations  correspond  to  about  1 8  hours  of  thunderstonn 
activity.  The  8,5 15  lightning  flashes  with  both  the  origin  point  and  at  least  75%  of  all 
points  that  are  not  influenced  by  bad  radar  data  represents  a  sustained  flash  rate  of  about 
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eight  flashes  per  minute  within  the  bounds  of  the  3D  radar  volume  coverage.  The  next 
section  presents  the  findings  resulting  from  the  processing  of  these  datasets. 


Table  3.  Final  Dataset  for  Composite  Reflectivity  Calculations. 


Date 

Number  of  LDAR  Points 

Number  of  Flashes 

Mean 

Points/Flash 

April  23,  1997 

239,277 

1,634 

1464 

August  3,  1997 

128,394 

1,156 

111.1 

February  23.  1998 

187,658 

2,549 

73.6 

July  6,  1998 

154,971 

1,165 

133.0 

February  28.  1999 

61,635 

201 

306.6 

June  11,  1999 

66,201 

656 

100.9 

March  31,  2000 

295,367 

1,640 

180.1 

July  7.  2000 

222,439 

2,361 

94.2 

March  29.  2001 

321,672 

3,043 

105.7 

June  15.  2001 

184,883 

5,218 

35.4 

Totals 

1,862,497 

19,623 

94.9 

Table  4.  Final  Dataset  for  Base  Reflectivity  Calculations. 


Date 

Number  of  LDAR  Points 

Number  of  Flashes 

Mean 

Points/Flash 

April  23,  1997 

92,989 

585 

159.0 

August  3,  1997 

7,708 

37 

208.3 

February  23, 1998 

92,432 

1,152 

80.2 

July  6,  1998 

71,140 

499 

142.6 

February  28, 1999 

25,282 

76 

332.7 

June  11,  1999 

43,255 

415 

104.2 

March  31,  2000 

146,637 

771 

190.2 

July  7,  2000 

80,597 

917 

87.9 

March  29,  2001 

209,196 

2,010 

104.1 

June  15.  2001 

69,968 

2,053 

34.1 

Totals 

839,204 

8,515 

98.6 
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IV.  Results  and  Analysis 


4.1.  Flash  Origin  Radar  Characteristics 

Determining  the  characteristic  traits  of  lightning  flash  origin  points  is  approached 
from  two  different  ways.  The  first  is  to  look  at  the  composite  reflectivity  signature  of  the 
LDAR  flash  origin  points  with  a  focus  on  the  requirements  for  Air  Force  weather 
personnel  to  make  decisions  about  the  issuance,  or  cancellation,  of  lightning  warnings. 
The  second  strategy  involves  focusing  on  the  3D  radar  reflectivity  environment  around 
these  lightning  flash  origins.  Using  the  results  from  this  3D  reflectivity  analysis,  better 
insight  into  the  radar  characteristics  of  lightning  flash  origins  are  possible.  An 
understanding  of  these  flash  origin  radar  traits  may  facilitate  making  aircrew  members 
more  aware  of  the  expected  lightning  threat  area  when  flying  near  thunders tonns. 

4.1.1.  Composite  Reflectivity.  Gremillion  and  Orville  (1999),  and  Hoffert  and 
Pearce  (1996),  suggest  that  lightning  flash  origin  points  are  normally  located  above  the 
main  reflectivity  core  or  hail  shaft.  The  mean  composite  reflectivity  of  these  lightning 
flash  origins  should,  in  theory,  be  fairly  high.  Therefore,  we  would  expect  to  find  that 
most  flash  origins  are  either  found  within  the  40-dBZ  composite  reflectivity  return,  or,  at 
the  least,  the  should  be  very  close  to  the  composite  reflectivity  core — depending  upon  the 
threshold  used  to  define  the  reflectivity  core  (recall  that  Hoffert  and  Pearce  used  30  dBZ). 

For  all  of  the  composite  reflectivity  results  discussed  herein,  19,623  lightning 
flashes — consisting  of  more  than  1.8  million  LDAR  data  points — were  merged  with  2D 
composite  radar  reflectivity  data.  The  mean  composite  radar  reflectivity  factor  of  the 
flash  origin  points  is  45.8  dBZ.  Figure  8  shows  the  cumulative  distribution  function 


40 


(CDF)  for  the  composite  reflectivity  of  the  lightning  origin  points.  The  CDF  presents  the 
data  in  a  way  that  makes  it  easy  to  determine  the  meaning  of  percentiles.  For  example,  it 
is  apparent  that  more  than  80%  of  all  flash  origin  points  had  a  composite  reflectivity  of 
greater  than  40  dBZ,  and  95%  of  the  origin  point  have  a  composite  reflectivity  of  more 
than  30  dBZ — the  lower  threshold  suggested  by  Floffert  and  Pearce  (1996).  About  40% 
of  the  flash  origin  points  have  a  composite  reflectivity  greater  than  50-dBZ. 


Figure  8.  CDF  of  Origin  Composite  Reflectivity.  The  cumulative  probability  of  composite  radar 
reflectivity  factor  (dBZ)  for  the  19,623  flash  origin  points  is  shown  here.  Examination  shows  that  95%  of 
all  flash  origins  have  a  composite  reflectivity  of  greater  than  30  dBZ.  90%  of  all  flash  origin  reflectivities 
are  greater  than  35  dBZ,  and  80%  of  the  origin  points  have  a  reflectivity  of  greater  than  40  dBZ. 


For  the  flash  origin  points  with  a  composite  reflectivity  of  less  than  40  dBZ,  just 

how  far  are  they  from  the  nearest  edge  of  the  nearest  40-dBZ  echo?  Or,  for  points  within 

the  40-dBZ  echo,  how  far  is  it  to  the  nearest  return  that  is  less  than  40  dBZ?  The  data 

verify  that,  indeed,  most  of  the  lightning  flashes  do  originate  either  within,  or  very  close 

to,  the  radar  reflectivity  cores.  Figure  9  is  the  CDF  for  the  horizontal  distance — since 

we’re  only  looking  at  2D,  planar,  radar  composites — from  the  flash  origin  point  to  the 
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edge  of  the  radar  echo  that  marks  the  40-dBZ  threshold.  For  points  within  the  composite 
reflectivity  core,  the  distance  (in  kilometers)  is  indicated  as  a  negative  distance,  measured 
to  the  nearest  composite  reflectivity  value  between  30  -  39  dBZ.  The  mean  horizontal 
distance  to  the  edge  of  the  reflectivity  core  for  this  dataset  is  -2.55  km. 


Figure  9.  CDF  of  Origin  Florizontal  Distance  from  40-dBZ  Echo.  This  plot  validates  that  80%  of  the 

flash  origin  points  were  indeed  within  the  40-dBZ  echo.  90%  of  all  flash  origins  are  either  within  the  40- 
dBZ  reflectivity  core,  or  are  less  than  1  km  from  the  outside  of  the  40-dBZ  threshold.  In  fact,  95%  of  all 
flash  origin  points  are  within  about  3  km  (about  1.6  NM)  of  the  of  this  40-dBZ  echo. 


As  is  expected  after  analyzing  the  distribution  of  flash  origin  composite 
reflectivity,  the  horizontal  distance  CDF  verifies  that  around  80%  of  the  flash  origin 
points  were  inside  the  radar  reflectivity  core.  It  is  also  evident  that  there  is  a  good 
agreement  between  the  40-dBZ  threshold  and  lightning  origin  locations — with  95%  of  all 
origins  either  within,  or  no  more  than  3  km  outside  of,  the  composite  reflectivity  core. 
This  suggests  that  there  may  be  a  potential  to  use  the  40-dBZ  line  as  a  critical  threshold 
for  determining  a  rule-of-thumb  for  lightning  warning  issuance,  or  cancellation,  criteria. 
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It  is  clear  that  lightning  flashes  do  indeed  appear  to  originate  in  the  vicinity  of  composite 
radar  reflectivity  cores,  but  what  about  the  actual  reflectivity  of  the  flash  origin  points? 

4.1.2,  Base  Reflectivity.  As  detailed  in  the  previous  chapter,  the  dataset  for  the 
base  reflectivity  analysis  is  much  smaller  due  to  radar  volume  processing  issues  and 
corruption  of  reflectivity  from  bad  data  values  in  the  interpolated  radar  volumes.  8,5 15 
lightning  flashes — made  up  of  839,204  LDAR  data  points — were  examined  to  determine 
the  base  reflectivity  values  and  distances  from  radar  reflectivity  cores.  The  mean  base 
radar  reflectivity  factor  for  the  flash  origin  points  is  33.5  dBZ — which  is  significantly  less 
than  the  mean  composite  reflectivity  of  flash  origins  of  45.8  dBZ.  Figure  10  shows  the 
CDF  for  the  base  reflectivity  results.  Whereas  90%  of  the  flash  origin  composite 
reflectivity  values  were  greater  than  30  dBZ,  for  base  reflectivity,  90%  of  the  flashes 
exceed  only  20  dBZ — which  would  correspond  to  the  outermost  edge  of  the  green 
reflectivity  displayed  by  the  C-17  radar. 

Recall  that  the  composite  reflectivity  data  suggested  that  the  lightning  origin 
points  are  normally  located  within  the  reflectivity  core.  The  base  reflectivity  data 
indicates  that  more  often  these  flash  origin  points  are  either  within  the  top  portion  of  the 
radar  reflectivity  core,  or  nearly  directly  above  the  reflectivity  cores.  This  is  further 
supported  by  the  fact  that  Boccippio  et  al.  (2001)  found  that  the  majority  of  LDAR  data 
points  tend  to  be  detected  at  around  9  km  (near  30  kft)  where  one  would  be  expected  to 
find  lower  base  reflectivity  values. 
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CDF  of  Flash  Origin  Base  Reflectivity 


Figure  10.  CDF  of  Flash  Origin  Base  Reflectivity.  The  8,515  flashes  considered  for  base  reflectivity 
indicate  that  about  90%  of  all  flash  origin  points  have  a  base  (3D)  radar  reflectivity  factor  of  greater  than 
about  20  dBZ — this  would  correspond  approximately  to  the  outer  edge  of  the  C-17’s  radar  display.  Only 
about  25  -  30%  of  all  flash  orgin  points  actually  were  initiated  within  the  40-dBZ  reflectivity  core. 


For  the  C-17  pilot  to  get  better  feeling  of  just  where  these  flashes  originate  with 
respect  to  the  radar  reflectivity  cores,  the  3D  distance  from  each  flash  origin  point  to  the 
edge  of  the  nearest  40-dBZ  base  reflectivity  echo  was  calculated.  The  mean  distance 
from  the  flash  origin  to  the  reflectivity  core  is  +0.8  km  (i.e.  outside  the  40-dBZ  core). 
Figure  1 1  displays  the  CDF  for  flash  origin  3D  distance  from  the  core  echo.  95%  of 
flashes  originated  within  6km  (about  3.2  NM)  of  the  radar  reflectivity  cores.  When 
combined  with  information  about  the  extent  that  flashes  tend  to  travel  horizontally  from 
the  flash  origin,  this  data  could  potentially  provide  insight  into  thunderstonn  avoidance 
criteria  based  upon  the  aircraft’s  distance  from  significant  radar  echoes.  Maximum 
lightning  flash  distances  from  the  origin  were  also  computed  during  the  processing  of  the 
flash  origin  data,  and  will  now  be  discussed. 
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Figure  11.  CDF  of  Origin  Distance  from  40-dBZ  Echo.  90%  of  the  8,515  flash  origins  examined  were 
located  within  about  4  km  (around  2  NM)  of  the  40-dBZ  radar  reflectivity  core.  The  data  verifies  that 
about  25%  of  the  flash  origins  are  actually  within  the  40-dBZ  echo.  95%  of  the  flash  origin  points  are  less 
than  about  6  km  (3.2  NM)  from  the  nearest  40-dBZ  echo.  (Note:  all  distances  are  actual  3D  distance,  not 

simply  horizontal  distance. 


4.2.  Overall  Flash  Distances 

Hundreds  of  lightning  flashes  were  plotted  over  composite  reflectivity  displays 
and  vertical  radar  cross-sections  and  visually  inspected.  It  became  evident  that  most  of 
the  lightning  flashes  did  tend  to  originate  near,  and  normally  above,  radar  reflectivity 
cores  (see  Figure  12).  Another  interesting  feature  that  stood  out  was  that  many  flashes 
that  branch  out  a  significant  horizontal  distance  from  the  flash  origin,  often  times  tend  to 
almost  follow  the  radar  reflectivity  contours.  With  this  empirical  trend  in  mind,  it 
seemed  fitting  to  try  to  encapsulate  some  basic  information  about  the  horizontal  extent 
that  lightning  flashes  travel,  not  only  from  the  source  point,  but  also  from  the  radar 
reflectivity  cores.  A  much  more  thorough  survey  of  this  type  of  data  using  the  entire 
LDAR  dataset  at  AFIT  is  currently  being  completed  by  Captain  David  Vollmer. 
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Figure  12.  Vertical  and  Horizontal  Lightning  Flash/Composite  Reflectivity  Image.  The  top  panel  is  a 
vertical  composite  reflectivity  image  (using  the  maximum  reflectivity  in  the  y-direction  to  determine  the 
composite  reflectivity  for  each  [x  ,  z]  grid  location)  with  data  points  from  a  single  lightning  flash  plotted. 

The  bottom  panel  is  a  planar  view  of  composite  reflectivity  for  the  same  radar  volume  with  the  same 
lightning  flash  plotted.  The  large  white  plus  sign  in  each  image  indicates  the  position  of  the  origin  of  the 
flash.  Note  that  this  origin  is  within  the  40-dBZ  echo  on  the  horizontal  view,  but  is  above  the  40-dBZ  core 

in  the  vertical  image. 

4.2.1.  Distance  from  Flash  Origin.  For  the  basic  investigation  into  how  far 
lightning  flashes  travel  horizontally,  the  composite  reflectivity  dataset  was  used.  It  must 
be  stated  that  since  the  criterion  used  to  process  the  dataset  called  for  only  using  flashes 
whose  entire  range  of  points  fell  wholly  within  the  bounds  radar  volume,  it  is  possible 
that  flashes  that  were  more  expansive  were  unintentionally  excluded  from  this  analysis. 
Again,  refer  to  Captain  Vollmer’s  thesis  for  a  more  detailed  analysis  of  flash  distance 
limits. 
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For  each  LDAR  data  point  in  a  lightning  flash,  the  horizontal  distance  between 
the  point  and  the  flash  origin  was  computed,  and  the  maximum  distance  for  the  flash 
recorded.  Certainly,  the  actual  horizontal  breadth  of  the  flashes  is  much  broader  than 
what  is  presented  here;  this  analysis  simply  takes  the  maximum  horizontal  distance  from 
origin  to  extreme  point — it  is  entirely  possible  that  the  actual  flash  extent  is  about  double 
the  distances  given  here.  The  CDF  of  the  results  of  this  simple  analysis  is  shown  in 
Figure  13.  The  mean  maximum  flash  distance  from  the  flash  origin  point  is  only  7.2  km 
(about  4  NM),  and  90%  of  the  flashes  had  a  maximum  horizontal  extent  of  less  than  16 
km  (or  8.6  NM  ).  Indeed,  95%  of  the  flashes  in  this  dataset  had  a  horizontal  limit  of 
about  19  km  (10.4  NM),  and  99%  were  less  than  30  km  (about  16.1  NM).  The  maximum 
flash  distance  in  these  nearly  20,000  flashes  was  about  46  km  (25  NM). 

4.2.2.  Distance  from  40-dBZ  Line.  As  mentioned  earlier,  a  subjective  analysis 
carried  out  while  watching  animated  plots  of  hundreds  of  lightning  flashes  indicated  that 
there  seemed  to  be  a  trend  for  the  main  part  of  a  flash  to,  in  general,  follow  the  areas  of 
high  reflectivity.  In  order  to  investigate  this,  the  base  reflectivity  dataset  was  analyzed  to 
detennine  the  maximum  distance  from  any  point  in  the  flash  to  the  nearest  radar 
reflectivity  core.  Again,  the  40-dBZ  threshold — inspired  by  the  work  of  Gremillion  and 
Orville  (1999),  and  made  a  prudent  choice  because  of  the  request  by  the  C-17  SPO — is 
used  to  represent  the  radar  reflectivity  core  for  distance  determinations.  The  distance 
here  is  the  point-to-point  3D  distance,  instead  of  the  horizontal  distances  in  the  previous 
section. 
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CDF  of  Maximum  Flash  Distance  from  Origin 


Figure  13.  CDF  of  Maximum  Flash  Distance  from  Origin.  This  shows  the  CDF  for  the  maximum 
horizontal  distance  from  the  flash  origin  point  to  the  furthest  LDAR  data  point  in  a  lightning  flash.  90%  of 
the  19,623  flashes  traveled  less  than  about  16  km  (8.6  NM)  horizontally  from  the  origin  point.  95%  travel 
less  than  around  19  km,  and  99%  traveled  less  than  30  km  (16. 1  NM)  from  the  flash  origin. 


Figure  14  is  the  CDF  for  the  maximum  flash  distance  from  the  40-dBZ  echo.  The 
distances  are  much  less  than  those  found  for  the  overall  flash  distance.  The  mean 
distance  from  the  core  echo  was  4.7  km  (2.5  NM).  In  contrast  to  the  maximum 
horizontal  distance  from  the  flash  origin,  where  it  was  found  that  99%  of  all  flashes 
traveled  less  than  about  30  km,  the  99th  percentile  for  the  flash  distance  from  the 
reflectivity  core  is  only  21  km  (11  NM). 

4.3.  Regime  Analysis 

The  results  presented  thus  far  are  based  upon  an  analysis  of  the  data  for  all  ten 
case  study  days.  The  composite  and  base  reflectivity  data  was  also  analyzed  based  upon 
the  weather  regime:  synoptic  or  airmass.  An  analysis  of  the  flash  origin  radar 
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Figure  14.  CDF  of  Maximum  Flash  Distance  from  40-dBZ  Echo.  This  shows  the  maximum  3D 
distance  that  the  furthest  point  from  the  flash  origin  traveled  from  the  edge  of  the  40-dBZ  echo.  90%  of  the 
8,515  flashes  had  a  maximum  distance  from  the  reflectivity  core  of  less  than  9  km  (~5  NM),  while  95% 
stayed  within  about  1 1  km  (6  NM)  of  the  nearest  40-dBZ  return.  99%  of  all  flashes  had  were  within  about 

21  km  (11.4  NM). 


characteristics  indicates  that  none  of  them  displays  an  operationally  significant  change 
between  the  two  regime  types.  The  flash  distances,  however,  do  show  a  change  that 
could  potentially  impact  recommendations  for  in-flight  lightning  avoidance. 


4.3.1.  Flash  Origin  Characteristics.  The  mean  value  of  flash  origin  base 
reflectivity  is  about  3-dBZ  higher  for  the  airmass  days  than  for  the  synoptic  days.  There 
is,  however,  almost  no  difference  at  all  in  values  of  the  90th  and  95th  percentiles  for  base 
reflectivity.  For  composite  reflectivity,  the  mean  reflectivity  of  the  flash  origins  is  less 
than  1  dBZ  higher  for  the  synoptic  days  than  for  the  airmass  days.  95%  of  all  flash 
origins  have  a  composite  reflectivity  greater  than  27  dBZ  for  the  airmass  days,  versus  33 
dBZ  for  the  synoptic  days.  A  similar  difference  exists  for  the  90th  percentile,  with  values 
of  composite  reflectivity  greater  than  33  dBZ  for  the  airmass  and  37  dBZ  for  the  synoptic 
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days.  To  understand  the  possible  operational  impact  of  these  variations,  the  flash  origin 
distance  data  must  also  be  considered. 

An  analysis  of  the  distribution  of  flash  origin  distances  from  core  radar  echoes 
indicates  that  the  mean  distance  inside  the  40-dBZ  composite  reflectivity  echoes  was 
slightly  greater  in  the  synoptic  cases.  But,  90%  of  the  flashes  originated  either  inside  the 
composite  reflectivity  core  or  within  about  1  km  of  the  edge  of  the  core  echo  in  both 
regimes;  and  95%  originated  within  3  km  of  the  40-dBZ  reflectivity  core  in  both  regimes, 
as  well.  The  continuity  in  the  spatial  relationship  between  the  flash  origins  and  the  radar 
reflectivity  cores  effectively  minimizes  any  impact  that  an  increase  in  the  mean  flash 
origin  composite  reflectivity  might  have  on  lightning  warning  guidance. 

4.3.2.  Flash  Distances.  A  significant  difference  exists  in  the  distribution  of 
maximum  flash  distance  from  the  flash  origin,  and  a  modest  difference  in  maximum  flash 
distance  from  the  40-dBZ  echos,  for  the  two  weather  regimes.  A  comparison  of  the 
CDF’s  of  maximum  flash  distance  from  the  flash  origin  is  shown  in  Figure  15.  The  mean 
maximum  flash  horizontal  distance  for  the  synoptic  days  was  8.2  km  (4.4  NM),  and  6.4 
km  (about  3.5  NM)  for  the  airmass  days.  The  90th  and  95th  percentiles,  however,  show  a 
more  pronounced  difference.  90%  of  flashes  on  ainnass  days  have  a  horizontal  extent  of 
less  than  13  km,  compared  to  18  km  on  synoptic  days.  95%  of  flashes  on  the  airmass 
days  had  a  maximum  flash  horizontal  distance  from  the  flash  origin  of  less  than  17  km; 
under  synoptic  conditions,  this  95th  percentile  extends  out  to  22  km.  The  same  trend 
toward  greater  flash  extent  with  synoptic  forcing  was  found  for  maximum  distance  from 
the  radar  echo  cores,  although  the  differences  observed  were  less  than  about  2  km 
between  the  two  regimes. 
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Figure  15.  CDF  Comparison  of  Maximum  Flash  Distance  from  Origin.  This  graph  shows  that  the 
90%  of  all  flashes  traveled  less  than  13  km  for  the  airmass  days  and  18  km  for  the  synoptic  days. 
Similarly,  95%  traveled  less  than  17  km  under  airmass  conditions  and  22  km  on  synoptic  days. 
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V.  Conclusion 


5.1.  Conclusions 

The  goal  of  this  research  was  to  examine  the  possibility  of  establishing  guidance 
for  aircraft  lightning  avoidance  and  lightning  warning  criteria  based  upon  the  radar 
reflectivity  signatures  of  lightning  flash  origins.  Based  upon  the  results  of  this 
investigation,  it  does  appear  feasible  to  come  up  with  such  guidance — both  for  in-flight 
thunderstorm  avoidance  and  cloud-to-ground  lightning  safety  criteria — that  uses  the  radar 
reflectivity  characteristics  of  lightning  source  points  as  basis  for  threat  area  identification. 
The  use  of  the  40-dBZ  threshold — which  was  selected  primarily  because  it  is  the  lower 
limit  of  the  maximum  reflectivity  displayed  by  the  C-17’s  radar  system — proved  to  be  an 
adequate  value  for  the  analysis  of  flash  origin  spatial  distribution. 

It  was  shown  that  95%  of  the  lightning  flashes  studied  originated  within  3  km  of  a 
40-dBZ  composite  reflectivity  echo,  with  80%  of  the  flashes  actually  originating  within 
the  40-dBZ  composite  reflectivity  echoes.  The  40-dBZ  composite  reflectivity  line  could 
be  used  as  a  trigger  for  when  to  issue,  or  cancel,  weather  warnings  for  lightning  at  Air 
Force  installations.  For  example,  issue  a  warning  once  the  40-dBZ  line  of  an  active 
thunderstorm — as  detennined  by  National  Lightning  Detection  Network  (NLDN) 
indications  of  CG  lightning  activity — comes  within  7  NM  of  the  warning  area  (assuming 
that  the  5  NM  radius  is  used).  This  could  be  especially  important  for  Operational 
Weather  Squadron  (OWS)  forecasters  responsible  for  issuing  warnings  for  all  bases 
within  their  area. 
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When  these  results  are  combined  with  the  findings  of  Captain  Todd  McNamara’s 
study  of  CG  lightning  distances  from  flash  origin  points,  the  adequateness  of  the  current 
five  nautical  mile  warning  radius  may  warrant  further  scrutiny  by  Air  Force  weather  and 
safety  policy  makers.  In  addition,  the  information  that  can  be  obtained  when  lightning 
and  radar  data  are  combined  emphasizes  the  requirement  for  better-integrated  lightning 
observing  systems.  This  is  especially  true  after  the  advent  of  the  OWS,  where  warning 
responsibility  rests  with  someone  outside  the  local  area.  The  task  of  keeping  track  of 
multiple  bases  and  knowing  when  to  issue/cancel  lightning  warnings  would  be  eased 
greatly  by  integration  of  NLDN  data  with  radar  displays,  and  preferably  with  3D 
lightning  mapping  systems  at  each  base  to  provide  a  total  lightning  picture. 

Merging  the  results  of  this  project  with  Captain  Dave  Vollmer’s  investigation  into 
flash  distances  by  altitude  and  atmospheric  temperature,  could  suggest  an  in-flight 
lightning  avoidance  rule-of-thumb  that  is  based  upon  the  radar  echoes  displayed  by 
onboard  radars.  The  flash  distance  results  derived  in  this  study — which  are,  admittedly, 
less  exhaustive  than  the  forthcoming  results  from  Captain  Vollmer’s  research — suggest 
that  95%  of  lightning  flashes  extend  less  than  19  km  (10.25  NM),  and  99%  traveled  less 
than  30  km  (16. 1  NM),  horizontally  from  the  flash  origin.  The  base  reflectivity  analysis 
of  more  than  8,500  flash  origin  points  revealed  that  95%  of  the  flashes  originated  within 
6  km  (or  3.2  NM)  of  the  nearest  40-dBZ  base  reflectivity  radar  echo.  Using  the  99th 
percentile  of  observed  flash  distance  (30  km),  for  optimum  safety  concern,  suggests  a 
safe  avoidance  distance  of  about  36  km  (just  under  20  NM)  from  the  nearest  40-dBZ 
radar  return. 
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The  data  also  suggest  that  a  less  restrictive  threshold  could  be  considered  based 
upon  the  observation  that  99%  of  all  flashes  traveled  no  further  than  21  km  3D  distance 
(about  1 1.3  NM)  from  the  nearest  40-dBZ  echo.  The  results  from  this  study  show  great 


promise  for  coming  up  with  practical  guidance  for  lightning  safety  based  upon  radar 
echoes  for  both  weather  personnel  and  aircrew  members.  There  is  one  main  limiting 
factor  that  will  be  discussed  in  the  next  section,  however,  that  would — at  least  at  this 
time — most  likely  preclude  widespread  guidance  being  developed  based  upon  these 
findings. 

5.2.  Recommendations  for  Future  Work 

The  fact  that  all  the  data  used  for  this  research  came  from  the  KSC  area,  may 
suggest  that  the  potential  guidance  stemming  from  this  research  might  be  valid  only  for 
flight  and  ground  operations  near  the  KSC.  Perhaps  the  results  might  be  representative  of 
thunderstorms  in  the  southeast  United  States,  but  what  about  the  rest  of  the  CONUS?  To 
address  the  limitations  on  the  applicability  of  the  findings  in  this  study,  3D  lightning  data 
from  different  geographical  regions  should  be  studied  in  the  same  manner. 

Until  recently,  the  only  other  3D  lightning  mapping  system  in  the  United  States 
was  the  system  owned  by  New  Mexico  Tech  for  research  purposes.  There  is,  however,  a 
new  system,  similar  to  LDAR,  being  operated  in  the  Dallas,  Texas  area  on  an 
experimental  basis.  The  possibility  of  obtaining  data  from  this  system,  and  merging  it 
with  WSR-88D  coverage  of  the  Dallas  area,  could  provide  an  opportunity  to  validate,  or 
perhaps  to  identify  a  regional  bias  in,  the  findings  of  this  study.  The  Dallas  data  may  also 
present  the  opportunity  to  study  different  types  of  thunderstorms,  such  as  supercells  and 
mesoscale  convective  complexes. 
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Appendix  A.  IDL  Flash  Grouping  Program 


The  flash-grouping  computer  code,  written  for  the  Interactive  Data  Language 
(IDL)  environment,  that  was  developed  using  the  NASA  flash-grouping  algorithm  as  a 
blueprint  is  presented  in  this  appendix.  This  code  is  included  to  allow  an  examination  of 
the  logic  used  to  group  individual  LDAR  data  points  into  lightning  flashes.  The  code 
accepts  the  file  name  of  the  raw  LDAR  data  file  to  be  processed  and  uses  the  same  file 
name  to  save  the  resulting  flash-grouped  LDAR  file.  The  raw  LDAR  data  is  assumed  to 
be  in  the  standard  ASCII  text  format  used  by  NASA.  The  comment  lines,  marked  by  a 
semicolon,  explain  what  each  section  of  code  is  doing. 


r 

;  Creates  a  Const  structure  to  hold  constants  that  can  be  passed  from 
;  function  to  funcion  by  only  passing  one  arguement 

r 

FUNCTION  Const 

C  =  {C,  xcal:-1318L,  $  ;  xpos  of  calibration  data 
ycal:-1609L,  $  ;  ypos  of  calibration  data 
zcal:450L,  $  ;  zpos  of  calibration  data 
dx:200L,  $  ;  look  +  /-  200m  from  xcal 
dy:200L,  $  ;  look  +/-  200m  from  ycal 
dz:450L,  $  ;  look  +/-  450m  from  zeal 

max_flash_time : 3 . OD,  $  ;  max  3  sec  from  start/stop  of  flash 
max_f lash_delay : 0 . 5D,  $;  max  time  lag  between  points  in  flash 
max_branch_delay : 0 . 03D,  $;  max  delay  between  points  in  a  branch 

Pi:3. 14159265359,  $ 

deg_to_rad: 3. 14159265359/180.0,  $  ;  degree  to  radain  conversion 
angle_error : 1 . OD,  $  ;  directly  from  NASA  code 

max_dis_f : 5000 . 0D,  $  ;  point  must  be  within  5km  to  be  in  flash 
block_size : 500L  }  ;  examine  500  LDAR  data  lines  at  a  time 

RETURN,  C 

END 
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;  data_line  Structure  definition.  LDAR  data  files  will  be  read  directly 
;  into  this  structure.  (Note:  ms,  x,  y,  z  are  LONG  integers) 

r 

FUNCTION  data_line 

DL  =  {DL,  day : 0 ,  $ 

hr:0,  $ 

min : 0 ,  $ 

sec:0,  $ 

ms:OL,  $ 

x : OL,  $ 

y : OL,  $ 

z:0L  } 

RETURN,  DL 

END 


r 

;  point_struct  definition.  This  structure  will  hold  the  seconds  (time), 
;  flash  number  (fnum),  branch  number  (bnum) ,  point  number  (index),  line 
;  number  of  the  parent  point  (parent),  and  line  number  (line_num)  of 
;  each  non_calibration  data  point  found. 

r 

FUNCTION  point_struct 
p  =  {p,  time:0.0D,  $ 
fnum:0L,  $ 
bnum:OL,  $ 
index : OL,  $ 
parent :0L,  $ 
line_num: OL} 

Return,  p 

END 


r 

;  flash_struct  definition.  Temporary  structure  that  will  hold  the  start 
;  time  (start_time)  in  seconds,  end  time  (end_time)  in  seconds,  number 
;  of  points  (num  points) ,  number  of  branches  (num_branches) ,  and  the 
;  line  number  of  the  first  point  ( f irst_point )  in  a  flash. 

• ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 

t 

FUNCTION  f lash_struct 

FL  =  {FL,  start_time : 0 . OD,  $ 
end_t ime : 0 . OD ,  $ 
num_points : OL,  $ 
num_branches : OL,  $ 
first_point : OL  } 

RETURN,  FL 

END 
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;  branch_struct  definition.  This  temporary  structure  will  hold  the 
;  start  time  (start_time)  in  seconds,  end  time  (end_time)  in  seconds, 

;  number  of  points  (num_points) ,  line  number  of  the  first  (first)  point, 
;  line  number  of  the  last  identified  point  (last),  line  number  of  the 
;  closest  point  (parent)  in  the  flash  to  the  first  point,  flash  number 
;  (fnum),  and  branch  number  (bnum)  for  an  active  branch. 

r 

FUNCTION  branch_struct 

BR  =  {BR,  start_time : 0 . OD,  $ 
end_time : 0 . OD ,  $ 
num_points : OL,  $ 
first :0L,  $ 
last : OL,  $ 
parent :0L,  $ 
fnum:OL,  $ 
bnum:0L  } 

RETURN,  BR 

END 


• ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 

/ 

;  Calculates  the  3-Dimensional  distance  between  two  points.  This 
;  function  accepts  two  point_stuct  type  arguements  pi  &  p2  and  uses 
;  pythagoream ' s  rule  to  determine  the  3D  distance. 


FUNCTION  dist_between_2_points,  pi,  p2 

RETURN,  sqrt ( ( (pi ,x*l .OD)  -  (p2 . x*l . OD) ) A2  +  $ 
(  (pi . y*l . OD)  -  (p2 . y*l . OD) ) A2  +  $ 
(  (pi . z*l . OD)  -  (p2 . z*l . OD) ) A2) 

END 


/ 

;  Calculates  the  2-Dimensional  horizontal  distance  between  two  points. 

;  This  function  accepts  two  point_stuct  type  arguements  pi  &  p2  and  uses 
;  pythagoream 1 s  rule  to  determine  the  2D  horizontal  distance. 

r 

FUNCTION  h_dist_between_2_points,  pi,  p2 

RETURN,  sqrt ( ( (pl.x*1.0D)  -  (p2 . x*l . OD) ) A2  +  $ 

( (pi . y*l . OD)  -  (p2.y*1.0D) ) A2) 

END 


/ 

;  range_error  was  directly  taken  from  the  NASA  flash  grouping  algorithm. 

r 

;  This  function  expects  a  floating  point  number  that  represents  the 
;  horizontal  distance  (in  meters)  from  the  LDAR  site  to  the  LDAR  event. 

;  The  range  error  is  determined  to  be  12%  of  the  range  (i.e.  if  an  event 
;  is  50km  from  the  LDAR  site,  the  range  error  is  6km) . 

r 

FUNCTION  range_error,  r 

return,  (r  *  12 . 0D/100 . OD) 

END 
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;  max_dis_b  was  directly  taken  from  the  NASA  flash  grouping  algorithm. 

t 

;  The  function  expects  a  floating  point  number  that  represents  the 
;  horizontal  distance  (in  meters)  from  the  LDAR  site  to  the  LDAR  event. 

t 

;  If  a  data  point  is  within  40km  of  the  LDAR  site,  a  max  horizontal 
;  distance  of  1km  is  used  to  determine  if  a  point  is  within  branch 
;  bounds.  Outside  of  40km,  this  distance  increases  from  1km  by  a  factor 
;  r / 4  0  km . 

r 

FUNCTION  max_dis_b,  r 

If  (r  LT  40000.0)  THEN  return,  1000. Od  ELSE  return,  r/40.0d 

END 


r 

;  is_point_in_f lash_bounds  is  a  modified  version  of  the  function  in  the 
;  NASA  flash  grouping  algorithm  by  the  same  name. 

r 

;  This  function  is  the  key  to  determining  whether  or  not  a  point  is  part 

;  of  a  flash  based  upon  spatial  constraints.  The  variables  passed  to 

;  the  function  are  the  point  to  be  checked  (pi  :  sub_d [ checki ] ]  from  the 
;  main  program) ,  the  group  of  data  being  examined  (data  :  sub_d  from  the 
;  main  program) ,  the  group  of  points  being  examined  (p  :  sub  p  from  the 

;  main  program) ,  the  flash  number  of  the  origin  of  the  flash  being 

;  examined  (fnum  :  sub  pfinitl . fnum  from  the  main  program),  the  origin 
;  data  point  (origin ...  has  location  [0,0,0]),  and  the  constant  structure 

;  c. 

r 

;  To  determine  if  a  point  is  within  flash  bounds,  the  radius  defined  in 
;  the  constant  structure  (C)  is  used  (Default  value  of  5000km  could  be 
;  modified  prior  to  compiling  and  running  the  program.  This  radius  is 
;  stored  in  the  C.max_dist_f  constant. 

/ 

;  An  ellipse  with  a  minor  axis  perpendicular  to  the  radial  between  the 
;  LDAR  site  and  the  the  point  being  considered  and  a  major  axis  along 
;  that  radial  is  used  to  determine  whether  or  not  a  point  is  within  the 
;  spatial  bounds  to  be  grouped  in  with  a  flash.  The  minor  axis  is  a 
;  function  of  C.max_dist_f  plus  the  azimuthal  error  of  LDAR.  The  major 
;  axis  is  also  a  function  of  C.max_dist_f  but  is  mainly  influenced  by 
;  the  range  error  of  the  LDAR  system. 

r 

;  The  function  returns  a  1  if  the  point  is  within  flash  bounds  and  a  0 
;  if  the  point  is  not  in  flash  bounds. 

r 

FUNCTION  is_point_in_f lash_bounds ,  pi,  data,  p,  fnum,  origin,  C 

;  locate  all  points  in  the  flash 

find  =  where (p. fnum  EQ  fnum,  cnt) 

;  p2  is  an  array  of  all  data  points  in  the  current  flash 

p2=data [find] 

;  thetal  indicates  the  angle  from  the  LDAR  point  to  the  point  pi 

thetal  =  atan  (pl.y  ,  pl.x  ) 

;  loop  through  all  points  (if  necessary) 

for  j  =  0L  ,  cnt-lL  DO  Begin 

;  make  sure  there  is  no  divide  by  zero  problem  with  finding  theta2 
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;  by  adding  lm  to  pl.x  if  x's  are  equal 

if  (p2[j] .x  EQ  pl.x)  then  pl.x  =  pl.x  +  1.0 

;  theta2  is  the  angle  between  the  current  flash  point  and  point  pi 

theta2  =  atan  ((p2[j].y  -  pl.y)  ,  (p2[j].x  -  pl.x)) 

;  alpha  is  the  differnce  in  the  two  angles,  and  represents  the  angle 
;  betweem  a  line  connecting  the  LDAR  site  to  point  pi  and  point  p2 

alpha  =  thetal  -  theta2 

;  determine  the  distance  to  point  pi  from  the  LDAR  site  (2D) 

range  =  h_dist_between_2_points  (  origin  ,  pi  ) 

;  calculate  distance  between  pi  and  the  current  point  in  the  flash  (2D) 

dis  =  h_dist_between_2_points  (pi  ,  p2[j]  ) 

;  a  is  the  minor  axis  of  the  ellipse  around  pi  and  represents  the 
;  azimuthal  error  of  the  LDAR  system 

a  =  C.max_dis_f  +  C . angle_error  *  C.deg_to_rad  *  range 

;  b  is  the  major  axis  of  the  ellipse  around  pi  and  represents  the  range 
;  error  of  the  LDAR  system 

b  =  C.max__dis_f  +  range_error  (  range  ) 

;  y  is  the  component  of  the  distance  between  pi  and  p2  that  is  parallel 
;  to  the  radial  from  the  LDAR  site  to  point  pi 

y  =  dis  *  cos  (  alpha  ) 

;  if  y  is  greater  than  the  major  axis  of  the  ellipse  there  is  no  way 

;  that  this  point  is  part  of  the  flash... also  avoids  an  imaginary 

;  number  when  calculating  x... 

if  (abs(y)  LE  abs (b) )  then  Begin 

;  solve  the  equation  of  the  ellipse  for  x  (all  other  variables  are  known 

x  =  a  *  sqrt  (  1 .  -  y*y/ (b*b)  ) 

;  determine  the  vector  distance  (in  ellipse  coordinates)  to  the  point 
;  x,  y  on  the  ellipse.  .  . 

dis_allowed  =  sqrt  (  x*x  +  y*y  ) 

;  If  the  distance  to  p2  is  less  than  dis_allowed,  p2  must  fall  inside 

;  the  ellipse  and  is  included  in  the  f lash ...  return  1  to  the  main 

;  program  to  indicate  success.  This  prevents  the  loop  from  continuing 
;  once  the  point  has  been  determined  to  belong  with  the  flash... 

if  (  dis  LE  dis_allowed  )  Then  return,  1 

endif;  end  of  If  (abs  (y)  LE  abs (b) )  . . . 

endfor 

;  If  we've  looked  at  all  points  in  the  flash  and  none  are  close  enough 
;  tell  main  program  this  point  is  not  part  of  flash... 

return,  0 

END 
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;  is_point_in_branch_bounds  is  a  modified  version  of  the  function  in  the 
;  NASA  flash  grouping  algorithm  by  the  same  name. 

t 

;  This  function  determines  whether  or  not  a  point  is  part  of  a  branch 
;  based  upon  spatial  constraints.  The  variables  passed  to  the  function 
;  are  the  point  to  be  checked  (pi  :  sub_d [checki ] ]  from  the  main 
;  program) ,  the  branch  number  to  check  (bn  :  bnum  from  the  main 

;  program) ,  the  group  of  data  being  examined  (data  :  sub_d  from  the  main 

;  program) ,  the  temporary  branch  structure  array  (b) ,  and  the  origin 
;  data  point  (origin ...  has  location  [0,0,0]) 

t 

;  The  function  returns  a  1  if  the  point  is  within  branch  bounds  and  a  0 

;  if  the  point  is  not  in  branch  bounds. 

t 

FUNCTION  is_point_in_branch_bounds,  pi,  bn,  data,  b,  origin 

;  determine  the  2D  range  from  the  LDAR  site  to  point  pi 

range  =  h_dist_between_2_points  (  origin  ,  pi  ) 

;  Check  the  distance  between  pi  and  the  last  point  in  the  current  branch 
;  and  compare  the  result  with  the  result  of  the  call  to  max_dis_b  for 
;  the  range  that  pi  is  from  the  LDAR  site.  .  . 

if  (h_dist_between_2_points (pi, data [b [bn] . last] )  LE  $ 
max_dis_b (range) )  Then  return,  1  else  return,  0 

END 


r 

;  find  closest  point  in  flash  is  called  if  a  point  is  found  to  be  within 
;  flash  bounds,  but  is  not  part  of  any  branch,  and  is  therefore  the 
;  first  point  in  a  new  branch.  This  function  determines  which  point  in 
;  the  flash  is  closest  and  that  point  will  be  the  "parent"  of  this  new 
;  branch. 

/ 

;  This  function  is  passed  both  the  data  structure  and  the  point 
;  structure  of  the  point  to  be  checked  (dl  :  sub_d [ check [ i ] ] 

;  from  the  main  program  and  ptl  :  sub_p [check [ i ] ]  from  the  main 
;  program) ,  as  well  as  the  data  and  point  sets  being  examined  (p  :  sub  p 
;  from  the  main  program  and  data  :  sub_d  from  the  main  program) . 

r 

;  The  3-Dimensional  distance  between  all  the  points  in  the  flash  and  ptl 
;  are  calculated  and  a  pointer  to  the  closest  point  is  returned. 

r 

FUNCTION  f ind_closest_point_in_f lash,  dl,  ptl,  p,  data 

;  Find  all  points  with  the  same  fnum. . .but  don't  include  point  ptl... 

j  =  where ( (p . fnum  EQ  ptl . fnum)  AND  (p.time  NE  ptl. time)) 

;  dist  will  be  a  vector  of  distances  calculated  between  all  points  &  ptl 

dist  =  dist_between_2_points (data [ j] , dl) 

;  find  the  shortest  distance 

shortest  =  min (dist) 

;  get  a  pointer  to  the  element  that  is  closest .  .  . 

index  =  where (dist  EQ  shortest,  count) 

;  if  there  are  more  than  one  point  with  same  distance ...  return  the  first 

if  (count  EQ  1)  then  return,  j [index]  else  return,  j[index[0]] 

END 


60 


Summary  of  Revisions: 

Version  Date  Changes 


1 . 0 

13 

Jul 

01 

Started  working  on  it . . . 

1 . 1 

19 

Jul 

01 

Modified  with  dialog_pickf ile ( ) 

1 . 2 

20 

Jul 

01 

Started  using  Structures... 

1.3 

28 

Aug 

01 

Bite-Sized  Chunks  added 

1 . 4 

04 

Sep 

01 

Finished  coding. .  .it  works!  !!!!!!! 

1.5 

24 

Oct 

01 

Completed  Documenting  Code 

Program  f lash_group . pro 
Date:  24  Oct  2001 
Version:  1.5 

Written  By:  lLt  Lee  A.  Nelson 

Purpose:  flash_group  reads  in  an  ASCII  text  file  from  a  user-specified 
location  (either  at  the  command  prompt  on  the  program  call,  or  in  a 
script  file,  or  by  use  of  a  dialog  pickfile  window  if  no  filename  is 
declared  when  the  program  is  called) . 

The  logic  for  this  code  comes  from  the  LDAR  flash  grouping  C  program 
used  by  NASA.  Very  slight  modifications  were  necessary  in  the  logic 
of  the  program.  The  entire  file  interface  is  different  from  the  NASA 
algorithm . 

The  output  file  are  saved  in  ASCII  text  format  using  the  identical 
file  name  as  the  LDAR  input  file.  As  such,  the  location  that  a  file 
is  saved  to  is  very  crucial.  As  with  our  LDAR  input  files,  the  naming 
convention  is: 

IdarYYYYMMDD . txt 

YYYY  -  Year 

MM  -  2  Digit  Month 

DD  -  2  Digit  Day 

The  data  in  the  output  file  includes  all  data  in  the  original  LDAR 
text  files:  Julian  Date,  Hour,  Minute,  Second,  Microsecond,  X,  Y,  and 
Z  locations,  plus  the  following  columns  of  data: 

Flash  Number:  (note  a  flash  number  of  -1  indicates  that  this  point 
was  either  a  lone  point  or  there  was  only  one  point 
with  flash  bounds,  and  no  two-point  flashes  are 
considered  to  be  valid  events) 


;  Branch  Number:  (note:  the  origin  of  a  flash  is  branch  number  0) 

r 

;  Point  Number  (or  index)  :  (indicates  position  within  a  branch ...  flash 
;  origin  is  Point  0) 

r 

;  Parent:  (the  first  point  in  a  branch  will  have  a  parent,  this  is  the 
;  point  in  the  flash  that  is  closest  to  the  first  point  in  a 

;  branch. . .most  points  will  not  have  a  parent. . .in  general  only 

;  points  with  a  point  number  of  1  will  have  a  valid  number  in 

;  the  parent  column) 

t 

;  Line  Number:  (a  unique  index  number  for  the  data  line,  useful  as  a 
;  pointer  and  a  sub-reference  when  only  parts  of  a  data 
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set  is  being  examined) 


;  The  IDL  Format  statement  to  read  these  output  files  is: 

t 

;  format  =  ' (i3,lx,i2,lx,i2,lx,i2,lx,i6,lx,i9,lx,i9,lx,i9,lx,i7'  +  $ 

;  ',lx,i7,lx,i7,lx,i7,lx,i7)' 

r 

pro  flash_group,  fname  =  fname 

close, /all  ;  Ensure  all  files  are  closed 

C=Const()  ;  call  Const  ()  function  to  define  constants... 

inpath  =  ' /home/fu jital2/ldar/data/ '  ;  modify  if  necessary 
outpath  =  ' /home/fujita7/nelson/flash/ 1  ;  modify  if  necessary 

;  Note:  the  outfile  has  the  identical  name  as  the  original  LDAR  file... 

infile  =  inpath+fname 
outfile  =  outpath+fname 

print,  infile  ;  show  name  of  input  file  on  screen 
n=0L  ;  initialize  the  line  count  holder 

clock  =  systime(l)  ;  initialize  the  clock  to  determine  run  time 

openr,  input,  infile,  /get_lun 

while  not  (eof (input))  do  begin  ;  loop  to  count  lines  of  data 
readf,  input,  s 
n  =  n  +  1L 
endwhile 

point_lun,  input,  0  ;  reset  pointer  to  first  line  of  file 

Line  =  data_line()  ;  Call  to  data_line()  creates  a  blank  structure 

data  =  replicate (Line, n)  ;  make  an  array  of  structures  to  hold  data 

readf,  input,  data  ;  fill  the  array  from  the  LDAR  file 

close,  input  ;  close  the  LDAR  file 
free_lun,  input  ;  free  the  pointer 

;  Filter  out  Calibration  Data  by  creating  an  array  of  pointers  to  the 
;  data  that  is  outside  of  the  calibration  "box" 

filter  =  where (( (data . x  LE  (c . xcal-c . dx) )  OR  $ 

(data.x  GE  (c . xcal+c . dx) ) )  OR  $ 

((data.y  LE  (c . ycal-c . dy) )  OR  $ 

(data.y  GE  (c . ycal+c . dy) ) )  OR  $ 

((data.z  LE  (c . zcal-c . dz) )  OR  $ 

(data.z  GE  (c . zcal+c . dz) ) ) ,  count) 

;  if  there  is  calibration  data  in  the  file. . .ignore  it. . .if  there  is 
;  only  calibration  data  in  the  file... reset  the  data  array  to  one  blank 
;  structure 

if  (count  NE  0)  then  data  =  data[filter]  else  data  =  data_line() 

;  there  may  be  some  "roll-over"  in  the  data,  assume  the  first  line  is 
;  on  the  first  day  of  data  and  assign  this  to  the  variable  date... 

date  =  data [0]. day 
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;  This  filters  out  any  data  with  date/time  data  that  is  not  correct... 

;  this  came  about  because  some  corrupted  data  was  found  that  had  bad 
;  date  data  and  garbage  positional  data... 

keep  =  where (( (data . day  EQ  date)  OR  (data. day  EQ  date+1)  AND  $ 
(data.hr  LE  23)  AND  (data. min  LE  59)  AND  $ 

(data. sec  LE  59)  ),  count) 

;  keep  any  "valid"  data... if  none... reset  data  array  to  one  blank  data 
;  structure 

if  (count  NE  0)  then  data  =  data[keep]  else  data  =  data_line() 

;  reset  the  counter  to  the  data  elements  left  after  filtering 

n  =  n_elements (data) 

;  call  the  point_struct ( )  function  to  define  a  point  structure  then 
;  make  n  copies  of  the  structure  to  hold  the  information  for  each 
;  point  in  the  data  array 

p  =  point_struct () 
p  =  replicate (p, n) 

;  initialize  the  line_num  elements  of  p 

p.line_num  =  lindgen(n) 

;  convert  the  time  elements  of  the  data  array  to  seconds  and  store  in 
;  the  time  element  of  p 

p.time  =  ((data. day  -  data [0] . day) *86400 . 0D)  +  (data . hr*3600 . 0D)  +  $ 
(data .min*60 . 0D)  +  (data. sec)  +  (data .ms/10 . 0DA6) 

;  define  the  origin ...  (note  x,y,z  =  0) 

origin  =  data_line() 

;  initialze  the  number  of  flashes  and  number  of  branches... 

num_flashes  =  0L 
num_branches  =  0L 

;  low  and  hi  will  keep  track  of  which  elements  of  the  data  and  p  arrays 
;  are  being  checked. .  . 

low  =  0L 

hi  =  C.block_size  -  1L 

;  if  there  are  more  elements  in  the  data  and  p  arrays  than  C.block_size 
;  make  a  sub_d  and  sub_p  array  that  holds  C.block_size  elements.  If  it 
;  is  a  small  data  set  with  C.block_size  elements  or  less,  then  make  the 
;  sub_d  and  sub_p  arrays  only  hold  n  elements.  The  critical_t  variable 
;  indicates  the  time  that  will  trigger  the  need  to  read  further  elements 
;  into  the  sub_d  and  sub  p  arrays.  This  critical  time  is  determined  by 
;  subtracting  C . max_f lash_time  seconds  from  the  last  element  in  the  sub 
;  array.  If  we  try  to  examine  any  point  as  the  possible  origin  of  a  new 
;  flash  that  is  within  C ,max_f lash_time  of  the  end  of  the  block,  we  need 
;  to  get  more  points  to  ensure  that  all  points  are  being  considered  that 
;  could  be  part  of  the  flash. . . 

if  (n  GT  C . block_size)  then  begin 

sub_d  =  data[low:hi]  ;  subset  of  data  to  be  checked 
sub_p  =  p[low:hi]  ;  subset  of  p  to  be  checked 

;  critical_t  will  trigger  the  process  of  getting  another  block  of  data 

critical_t  =  sub_p [hi] . time  -  C .max_flash_time 

;  prepare  for  the  next  block  of  data  to  be  checked ...  reset  low  and  hi 

low  =  low  +  C.block_size 
hi  =  hi  +  C.block_size 

endif  Else  Begin  ;  if  this  is  a  small  data  set... only  one  block 
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sub_d  =  data 
sub_p  =  p 

hi  =  n  ;  this  will  ensure  no  more  blocks  of  data  are  checked 

critical_t  =  sub_p [hi-lL] . time  -  C . max_f lash_time 
endelse 

stop  is  a  flase  flag  that  allows  entry  into  the  while  loop,  exiting 
the  loop  is  handled  by  a  break  statement  once  conditions  are  met. . . 

stop  =  0 

this  loop  repeats  until  there  are  no  more  points  to  examine... 

while  (stop  NE  1)  DO  Begin 

define  a  blank  branch  structure  (note:  this  discards  any  data  from 
prior  flashes.  .  . 

b  =  branch_struct ( ) 

init  is  a  pointer  to  the  first  element  with  a  flash  number  of  zero 

init  =  min (where (sub_p . fnum  EQ  0,  count)) 

make  sure  there  is  at  least  one  point  with  a  flash  number  of  zero 

if  (count  EQ  0)  then  Begin  ;  if  there  is  not... 

if  this  the  last  last  block  of  data  (i.e.  hi  =  n)  then  stop  the  loop 

if  (hi  EQ  n)  then  break  $;  exits  while  loop... 

if  there  are  more  points. . .get  another  block  of  data. . . 

else  begin 

if  there  are  more  than  C.block_size  points  left... then 

if  (hi  +  C.block_size  LT  n)  then  begin 

get  the  next  block  of  data  from  low  to  hi 

sub_d  =  data [low: hi] 
sub_p  =  p[low:hi] 

define  the  new  critical_t 

critical_t  =  p [hi-lL] . time  -  C .max_flash_time 

reset  the  low  and  hi  pointers  for  the  next  block  of  data 

low  =  low  +  C.block_size 
hi  =  hi  +  C.block_size 

or  if  there  are  less  than  C.block_size  points  left... 

endif  Else  Begin 

get  the  remainder  of  points  to  be  checked 

sub_d  =  data [low : n-lL] 
sub_p  =  p[low:n-lL] 

set  hi  =  n  to  trigger  check  that  no  more  data  left. . . 

hi  =  n 

set  new  critical_t 

critical_t  =  p [hi-lL] . time  -  C .max_flash_time 
endelse 

now  go  back  to  the  first  statement  in  the  WHILE  loop  and  look  again 

Continue 

endelse 

endif  ;  ends  the  IF  (COUNT  EQ  0)  statement. . . 
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If  we're  near  the  end  of  the  block  (time-wise)  and  this  isn't  the  last 
block  of  data  to  check,  filter  out  the  data  that  has  already  got  a 
flash  number,  and  then  add  another  block  of  data  to  what's  left  in 
sub_d  and  sub_p . . . 

if  ( (sub_p [init] .time  GT  critical_t)  AND  (hi  NE  n) )  THEN  Begin 

we'll  keep  all  the  points  that  haven't  been  assigned  a  flash  number 

keep  =  where (sub_p . fnum  EQ  0,  cnt) 
sub_p  =  sub_p[keep] 
sub_d  =  sub_d[keep] 

if  there  are  at  least  C.block_size  elements  left  in  data  and  p... 

if  (hi  +  C.block_size  LT  n)  then  begin 

append  another  block  from  low  to  hi  on  to  sub_d  and  sub_p 

sub_d  =  [sub_d, data [low : hi] ] 
sub_p  =  [sub_p,p[low:hi] ] 

calculate  a  new  critical_t 

critical_t  =  p [hi-lL] . time  -  C . max_f lash_time 

reset  low  and  hi  for  next  block  of  data 

low  =  low  +  C.block_size 
hi  =  hi  +  C.block_size 

if  there  are  less  than  C.block_size  points  left... 

endif  Else  Begin 

get  the  rest  of  the  points  and  append  to  sub_d  and  sub_p 

sub_d  =  [sub_d, data [low : n-lL] ] 
sub_p  =  [sub_p,p[low:n-lL] ] 

set  hi  =  n  to  trigger  flag  that  this  is  last  block  of  data 

hi  =  n 

determine  new  critical_t 

critical_t  =  p [hi-lL] . time  -  C .max_flash_time 
endelse 

now,  go  back  to  first  statement  in  WHILE  loop  and  start  again. . . 

continue 

endif 

note:  only  get  here  if  the  all  the  points  within  C .max_f lash_time 
seconds  are  included  in  this  block  of  data,  or  if  this  is  the  last 
part  of  the  data  file  and  no  more  data  can  be  added  to  sub_d  and 
sub_p 

check  is  an  array  of  pointers  to  the  elements  of  sub  p  and  sub_d  that 
are  within  C .max_f lash_time  seconds  of  the  time  of  the  point  that  init 
points  to  and  have  no  flash  number  yet  assigned... 

check  =  where  (  (sub_p . time  GT  sub_p[init] .time)  AND  $ 

(sub_p.time  LE  (sub_p [init] . time  +  C . max_f lash_time) )  $ 
AND  ( sub_p . fnum  EQ  0 ) ,  count ) 

if  we  don't  find  any  points  that  meet  the  above  criteria ...  set  fnum  to 
-1  to  indicate  not  part  of  a  valid  flash... 

if  (count  EQ  0)  then  begin 
sub_p[init] .fnum  =  -1L 

use  the  line_num  of  the  sub_p  element  to  reference  the  actual  data 
in  the  p  array  and  set  fnum  to  -1  as  well 
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p [sub_p [init] . line_num] . f num  =  -1L 

if  there  are  points  to  check ...  check  them 

endif  ELSE  Begin 

initialize  a  temporary  flash  structure... 

f_temp  =  flash_struct () 

f_temp . f irst_point  =  sub_p [init] . line_num 
f_temp . start_time  =  sub_p [ init ] . time 
f_temp . end_time  =  f_temp . start_time 
f_temp .  num_points  =  ftemp .  num__points+l 

initialize  the  flash  number  of  the  init  point... 

sub_p [ init ]. f num  =  num_f lashes+lL 
p [sub_p [init] . line_num] . f num  =  num_f lashes+lL 

initialize  a  temporary  branch  structure 

b_temp  =  branch_struct ( ) 
b_temp . fnum  =  num_f lashes+lL 

b_temp . parent  =  sub_p [init] . line_num  ;  init  is  parent... 

recall  that  count  is  the  number  of  points  in  check. .  .that  is,  the 
number  of  points  with  no  flash  number  and  within  C .max_f lash_time 
seconds  of  init . . . 

for  i  =  OL,  count-1  DO  Begin 

check  to  see  if  the  point  is  within  the  proper  temporal  (within 
C . max_f lash_delay  seconds  of  the  last  point  in  the  flash)  and 
spatial  window  to  be  considered  part  of  the  flash... 

if  (( (sub_p [check [i] ]. time-f_temp . end_time)  LE  C . max_f lash_delay)  $ 
AND  (is_point_in_f lash_bounds (sub_d [check [i] ] , $ 

sub_d, sub_p, sub_p [init] . fnum, origin, C)  EQ  1))  $ 

THEN  Begin  ;  if  it  is  within  time  and  space  bounds... 

set  flash  number  in  sub_p  and  p. . . 

sub_p [check [i] ] .fnum  =  sub_p[init] .fnum 

p [sub_p [check [i] ] . line_num] .fnum  =  sub_p[init] .fnum 

set  flash  end_time  to  this  point's  time 

f_temp . end_time  =  sub_p [check [i] ]. time 

increment  the  number  of  points  in  the  flash... 

f_temp . num_points  =  f_temp . num_points+lL 

check  to  see  if  this  is  the  first  branch  in  the  flash. . .if  it  is. . . 

if  (f_temp . num_branches  EQ  0)  then  Begin 

initialize  the  branch  information  for  the  first  point... 

sub_p [check [i] ] .bnum  =  1L 
sub_p [check [i] ]. index  =  1L 
p [sub_p [check [i] ]. line_num] .bnum  =  1L 
p [sub_p [check [i] ]. line_num] . index  =  1L 

initialize  the  b_temp  information  with  the  info  from  the  current  point 

b_temp . start_time=  sub_p [check [i] ] . time 

b_temp . end_time  =  b_temp . start_time 

b_temp. first  =  check [i] 

b_temp.last  =  check [i] 

b_temp.bnum  =  1L 

b_temp . num_points  =  1L 

f_temp . num_branches  =  1L 

b  =  [b,b_temp];  add  branch  to  structure 
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note:  the  parent  is  the  line_num  of  init . . . 

sub_p [check [i] ] .parent  =  b_temp . parent 
p [sub_p [check [i] ] .line_num] .parent=  b_temp . parent 

if  there  is  already  at  least  one  branch  in  the  current  flash... 

endif  else  Begin 

found  is  a  flag  to  stop  looping  once  we  find  a  branch  for  this  point 

found  =  0 

look  through  all  branches  to  determine  if  point  is  part  of  a  branch 

for  j  =  1L, f_temp . num_branches  Do  Begin 

if  we  haven't  found  a  branch ...  then 

if  (found  EQ  0)  Then  Begin 

Check  if  point  is  within  temporal  (C .max_branch_delay  seconds)  and 
spatial  bounds  of  the  last  point  in  the  current  branch 

if  ( (sub_p [check [i] ]. time  -  b [ j ] . end_time  LE  $ 

C .max_branch_delay)  AND  (is_point_in_branch_bounds  $ 
( sub_d [check [i] ] ,  j,  sub_d,  b,  origin)  EQ  1) )  $ 
Then  Begin  ;  if  part  of  this  branch 

set  end_time  of  branch. . . 

b [ j ] . end_time  =  sub_p [check [i] ]. time 

increment  number  of  points  in  this  branch... 

b[j] .num_points  =  b[j] .num_points  +  1L 

set  branch  number  of  point  in  sub_p  and  p. . . 

sub_p [check [i] ] .bnum  =  j 
p [sub_p [check [i] ] . line_num] .bnum  =  j 

set  index  number  for  this  point  in  p  and  sub  p . . . 

p [sub_p [check [i] ]. line_num] . index  =  b [ j ] . num_points 
sub_p [check [i] ]. index  =  b [ j ] . num_points 

set  pointer  to  the  last  element  of  the  branch  to  current  point. . . 

b[j].last  =  check[i] 

set  flag  to  stop  looping  for  this  point... 

found  =  1 
endif 
endif 
endf or 


if  we  didn't  find  a  branch  for  the  point. . .must  be  a  new  branch. . . 

if  (found  EQ  0)  Then  Begin 


find  the  closes  point  in  the  flash  to  this  point... 

nearest  =  f ind_closest_point_in_f lash  (sub_d [check [i] ] ,  $ 

sub_p [ check [ i ] ] ,  sub_p , sub_d) 


create  a  new  brach  element . . . 

b_temp  =  branch_struct ( ) 

parent  of  new  branch  is  nearest  point  in  the  flash... 

b_temp . parent  =  sub_p [nearest] . line_num 

assign  parent  to  sub  p  and  p  point  as  well. . . 

p [sub_p [check [i] ]. line_num] .parent  =  b_temp . parent 
sub_p [check [i] ] .parent  =  b_temp . parent 
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assign  flash  number 

b_temp . fnum  =  sub_p [check [i] ] . fnum 

initialize  first  and  last  of  new  branch  element... 

b_temp. first  =  [check [i] ] 
b_temp.last  =  check [i] 

increment  number  of  branches  in  the  flash... 

f_temp . num_branches  =  f_temp . num_branches  +  1L 

assign  a  branch  number  to  the  new  branch... 

b_temp.bnum  =  f_temp . num_branches 

initialize  the  start  and  end  time  of  the  new  branch... 

b_temp . start_time  =  sub_p [check [i] ]. time 
b_temp . end_time  =  sub_p [check [i] ]. time 

set  the  number  of  points  in  the  new  branch  to  1 

b_temp . num_points  =  1L 

update  p  and  sub  p  with  branch  number  &  index 

p [sub_p [check [i] ] . line_num] .bnum  =  b_temp.bnum 
sub_p [check [i] ] .bnum  =  b_temp.bnum 
sub_p [check [i] ]. index  =  1L 
p [sub_p [check [i] ]. line_num] . index  =  1L 

append  b_temp  to  b. . . 

b  =  [b,b_temp] 

endif  ;  end  of  IF  (found  EQ  0) . . . 

endelse 

endif 

endfor  ;  end  of  for  loop  to  check  all  points.  .  . 
note:  we  get  here  when  we've  checked  all  points 

A  flash  will  only  be  considered  valid  if  there  are  more  than  2  data 
points  in  the  flash.  .  . 

If  (f_temp . num_points  GT  2)  THEN  Begin  ;  if  a  valid  flash... 

increment  number  of  flashes... 

num_flashes  =  num_f lashes+lL 

complete  indicates  the  percentage  of  points  examined  thus  far... it 
is  echoed  to  the  screen  as  a  visual  check  for  how  much  progress  is 
being  made . . . 

complete  =  ( (sub_p [init] . line_num*l . 0)  /  $ 

(n_elements (data) *1.0)) *100 . 0 

show  the  progress  on  the  screen  (flash  number,  %  done,  etc... 

print,  complete,  '%  flash  number:  ',  num_f lashes,  $ 

'  index:  ',  sub_p[init] . line_num,  1  time  : ',  $ 

sub_d [ init ]. day,  sub_d[init] .hr,  sub_d[ init] .min,  $ 
sub_d [ init ]. sec,  sub_d[init] .ms,  $ 
format  =  " (f6 . 2,  al6, i8, a8, i8, a7, 4i3, i7) " 

if  this  was  not  a  valid  flash  (i.e.  not  more  than  2  points  in  flash) 

endif  else  Begin 

set  init  point  flash  number  to  -1  to  indicate  not  a  valid  flash... 

sub_p[init] .fnum  =  -1L 
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p [sub_p [init] . line_num] . fnum  =  -1L 

;  find  the  points  in  sub_p  that  were  part  of  this  possible  flash... 

reset  =  where (sub_p . fnum  EQ  num_flashes  +1L,  count) 

if  (count  NE  0)  then  Begin 

;  find  the  points  in  p  that  were  part  of  this  possible  flash,  too... 

reset2  =  where (p. fnum  EQ  num_f lashes  +  1L) 

;  reset  the  flash  number,  parent,  and  index  of  each  point... 

sub_p [reset] .fnum  =  0L 
sub_p [reset] .parent  =  0L 
sub_b [reset] . index  =  0L 
p[reset2] .fnum  =  0L 
p [reset2] .parent  =  0L 
p [reset2] . index  =  0L 
endif 
endelse 
endelse 

END  ;  end  of  while  loop 

;  open  the  output  file  for  writing... 

openw,  output,  outfile,  /get_lun 

;  write  the  output  for  each  line  of  data  in  the  data  and  p  arrays. . . 

for  i  =  0L,  n_elements (p)  -  1  DO  begin 

printf,  output,  data[i].day,  data[i].hr,  data[i].min,  $ 

data[i].sec,  data[i].ms,  data[i].x,  data[i].y,  data[i].z,  $ 
p[i].fnum,  p[i].bnum,  p[i], index,  p[i], parent,  $ 
p [i] . line_num,  format  =  " (4i3, i7, 3il0, 5i8) " 

endfor 

close,  /all  ;  close  all  files 

free_lun,  output  ;  free  the  pointer  to  the  output  file... 

;  echo  to  the  screen  how  many  points  were  not  part  of  a  flash. . . 

print,  n_elements (where (p . fnum  LT  0) ) ,  '  item(s)  out  of  1 ,  $ 
n_elements (p) , '  were  not  part  of  a  flash' 

;  echo  to  screen  how  long  it  took  to  complete  the  program. . . 

print,  'It  took  ',  systime (1) -clock,  '  seconds  to  run  this...'  ,  $ 
format  =  " (a8, fl2 . 1, a23) " 

;  echo  to  screen  that  the  program  execution  is  complete... 

print,  ' done . . . ' 

end  ;  end  of  Program 
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Appendix  B.  Examples  of  Radar  Processing  Errors 


Two  figures  are  include  in  this  appendix  to  graphically  show  two  of  the  types  of 
data  problems  found  when  using  the  SPRINT  and  CEDRIC  software  to  interpolate 
archive  Level  II  radar  reflectivity  data  to  a  3D  Cartesian  grid.  Figure  16  shows  a  radar 
volume  that  was  deemed  unusable  due  to  the  large  amount  of  missing  data  in  the  lower 
levels — were  we’d  expect  to  find  some  of  the  higher  reflectivity  returns.  There  is  a 
distinct  line  that  shows  that  only  part  of  one  of  the  elevation  scans  was  processed,  with 
several  missing  altogether. 


A  Large  Amount  Were  High-Reflectivity 

of  Missing  Data  Data  is  Missing 


Figure  16.  Example  of  an  Unusable  Radar  Volume.  This  image  shows  a  radar  volume  that  was 
considered  unusable  because  crucial  reflectivity  information  is  missing.  The  distinct  line  of  where  the 
reflectivity  is  missing,  combined  with  the  fact  that  much  of  the  lower  levels  of  the  radar  echoes  are  missing, 
makes  this  volume  unfit  for  even  composite  reflectivity  calculations. 


Figure  17  is  an  example  of  a  radar  volume  that  was  declared  to  be  partially  usable. 
This  indicates  that  some  of  the  data  is  missing,  but  a  subjective  analysis  indicated  that 
enough  of  the  higher  reflectivity  values  are  present  that  would  facilitate  a  composite 
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reflectivity  grid  being  created  from  the  valid  data  in  the  volume.  In  the  volume  shown, 
there  is  a  large  slice  of  the  mid  levels  of  the  storm  missing,  but  it  is  clear  that  most  of  the 
higher  reflectivity  values  are  included  in  the  available  data.  Radar  volumes  such  as  this 
were  used  for  composite  reflectivity  calculations — and  the  distance  calculations  based 
upon  composite  reflectivity  grids.  These  partially  usable  volumes  were  not  used, 
however,  for  any  base  reflectivity  computations. 


A  Large  Amount 
of  Missing  Data 


Figure  17.  Example  of  a  Partially  Usable  Radar  Volume.  This  image  shows  a  radar  volume  that  was 
considered  partially  usable.  A  rather  large  slice  of  the  volume  is  missing,  however,  it  lies  above  the  region 
of  highest  reflectivity,  making  it  very  likely  that  a  composite  reflecivity  grid  created  by  a  complete  volume 
and  one  created  from  this  3D  grid  would  be  essentially  equivalent. 
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